Cost overruns, missed schedules and quality issues. These were the reasons cited for the development of Scrum.
Management also wants to harvest the business value expected from new software sooner, while using fewer resources
Breaking a traditional process up into small increments solves all of these problems. MSFis a wonderful example of this apart from the fewer resources bit, that is a myth. MSF encourages the business to develop a long term vision for the solution, but then it is broken into a series of small deliverables that build up in timeboxes to a full solution, or stop when time or budget run out.
The benefits are significant because; a. A proper Enterprise Architecture, style and vision is agreed first. That means that we don’t start off with one approach then half way through have to scrap it all and start again in order to scale. B. It means that at the end of the first timebox there is something of business value to show to the customer.
MSF differs from scrum however, in that it still depends on some basic documentation and designs and formal testing in a way that is familiar to most software engineers. MSF also lends itself well to procuring systems which I can’t honestly say about Scrum.
The downside is that MSF does not greatly improve communication other than the fact that it keeps the timeboxes short and encourages a collaborative agile team of peers, but the documentation still poses a threat to communication.
Scrum is a very different kettle of fish.
Scrum is designed to address a number of other problems:
- The Product Owner is a response to the lack of communication in traditional projects caused by remote stakeholders and by the sheer challenge of communicating a business idea from an executive to a programmer or architect accurately. Putting the business person in the role of Product Owner broke through this barrier.
- Demotivated and remote “techies” interested only in playing with gadgets is also a perception that still exists and it is countered by empowering them, making them into generalists and putting them in daily communication with their customer in the business.
Fear of not knowing what “they are doing in there” is still an irrational fear that plagues the relationship between technology and the business. Delivering demonstrable pieces of functionality at regular intervals lets the business see proof that they are working and usually sends them off to sleep within a few months.
Aspects of Scrum that pose serious threats to success of a project
- Scrum was designed for writing code for fairly small projects. It was never designed to be used for many of the other unbelievable uses it is put to. The reason for some of these ridiculous applications of Scrum may be that Project management skills have been deprecated in favour of” the new thing”. The chances are they were not great to begin with and hence the adaption of Scrum
- Scrum is NOT Project Management, it’s designed by software engineers for software development. In small projects, the Product Owner could carry in his head all the stuff normally entrusted to a project and the scrum master can run the development, but this does not translate to bigger projects.
Scope creep. Yes, we thought we had beat this one but in fact the reality is often that Scrum introduces a crippling level of scope creep. Three reasons mainly are to blame:
- No formal change control, nobody to say ” you are kidding?” so everything goes on the backlog
- No formal end date, so as long as it is all cosy, the business customer will keep on going, why should he stop?
- Bugs and millions more of them. Scrum teams don’t do formal testing and if you ever developed software you know what this means . Scrum teams also decide which bugs to fix and which to ignore. Naturally this becomes a tool when meeting the end of sprint deadline, it may be that the system works, but only just. That is acceptable by the way.
- A Scrum of Scrums is like replacing a big house with a tower block. It isn’t smaller or more manageable, it’s a mess. We spent the last twenty years turning old fashioned command and control organisations into flat collaborative ones. Now the scalable Scrum has built them back up again with a cell of cells like a medieval army. I’m not saying its impossible, just that it needs improvement and it’s not always worth the effort.
- Estimating is very difficult and Sprints are far worse at predicting their time and scope than traditional projects ever were. Costs are sometimes spiralling rather than falling, they just are not visibly so.
- Frequently the techies dominate the Product owner to get their own way and the collaboration is little more than a nice theory, the difference is he won’t tell anyone.
- Scrum was designed to be done by very experienced engineers all of whom were trained in Scrum. In reality few team members are even certified and the engineering skills are generally not good enough for a self-contained empowered team
- If any of the team members leave it can have a serious effect on the outcome.
- Scrumbut is a major problem. It refers to the practice of leaving out key parts of the process because you don’t like them, or whatever excuse. The problem is that velocity charts, retrospect and all the other rituals are there for a very good reason and when left out you end up with a traditional bunch of techies running amok with no controls, planning, or performance improvement strategy.
- The hatred of documents and authority figures really hurts when it comes to architecture.
The team gradually becomes braver and makes more unqualified assumptions about the underlying infrastructure they are building on until eventually disaster happens and when it does there is no documentation, the designer has left and there is chaos.
So what should do you need to do if you are considering a Scrum implementation in your organisation?
- Begin by spending as much time as necessary to be very clear about what problem you hope to resolve with Scrum, or what benefit you want to reap.
Don’t implement Scrum to deliver major projects, it was never designed for this. If you want to add some of the elements of incremental delivery etc, go ahead and introduce them to your traditional approach, or explore another method such as MSF.
Define your criteria for deciding whether a project should be approached in a traditional way or via Scrum. Get advice if needed and especially in the first year, be very careful to tackle only projects that lend themselves to Scrum. As a guideline I would say:
- They should have a small element of invisible work, i.e. if there’s two months work to implement stuff you can’t demonstrate, don’t tackle this one with Scrum at least not till you are very experienced.
- The solution must be something that lends itself to incremental delivery and can be meaningfully demonstrated.
- The whole team including Product Owner can be located in the same building and I would try to get the Product Owner relocated to sit with the team.
- Define a clear framework for Enterprise Architecture and let the Scrum team clearly understand what they can touch and what they can not and don’t budge on change control mechanisms when it comes to mission critical systems and those that impact them.
In TOGAF terms a good approach might be to say that only the Organisation specific technology can be touched and within that I might label parts of it uniquely for agile access.
- Don’t start with a team who have let you down at traditional approaches and read an ebook on Scrum. Send them away for a few days to be trained and hire an experienced person to coach the team through at least their first project.
- Put in place a QA process to monitor Scrum and their performance. Make sure that all the rituals are being done and in a meaningful way. Make sure the velocity is being monitored, monitor the accuracy of estimations, watch out for debt in the bugs department.
- Most of all, when you have a good plan in place and you are satisfied that you have the answers to hand, present your plan to your colleagues in the business in the context of how it will be impacting them, how they will benefit and how they will be expected to change the way they engage. Make necessary changes and then plan for the launch.
- This is really important. Take a cold look at your existing project management processes and ask yourself what is it that made you so keen to try an alternative approach. If some of these issues are not going to be solved by Scrum and I predict that will be the case, then set about resolving them in another way.
- Make sure you have a clear interface defined for how Scrum teams will interact with traditional projects and Programmes when asked to do so. There must be no them and us, but on the contrary, the two disciplines must support each other. You will need your programme and project management capabilities for many things and it will be beneficial to be able to interface a Scrum project with part of a project or a programme without ruffling feathers. This will also save you from the ignominy of trying to deliver huge projects via Scrum