The biggest myth about scrum project management
The growth in scrum project management
Look on the website of any software development company nowadays, and you'll probably see claims of agile development methods. You may even see the term scrum mentioned.
Scrum is the popular choice of late. It has become fashionable due to a modern and simple methodology, promoted heavily by training companies who can offer certification in this technique. It has received great feedback from technology companies and from developers in particular, who embrace the methodology for its skill in making all team members feel involved in the project. It is less dictatorial.
Yet one myth continues to persist. Many companies, and managers in particular, are drawn to scrum as a way of speeding up projects through rapid development. The perception of scrum is that it requires less planning, fewer documents, and will result in a quicker project.
Wrong. I'll explain why.
Planning is central to scrum project management
Planning is actually a core component of scrum. The reason it doesn't get the same bad press that planning does with traditional project methodologies is because it is spread more evenly across the project rather than assigned its own phase at the start. Its only when assigning 'planning' to an entire phase does it become high profile and risk the scrutiny of the senior management team who wonder why you aren't 'getting on' with the tasks in hand.
Planning time compared to traditional project management methodologies
I looked at 50 past projects I managed and did a data comparison between how much planning time was spent on Scrum projects compared to more traditional methods (in this case, PRINCE2). The result? Of all the time booked on the project, 25% of that could be attributed to planning on a PRINCE2 project, and this rose to 30% on scrum.
So what planning happens on a scrum project?
So let's look at the evidence. What planning activities happen on a scrum project?
1) The product backlog
The product owner creates the list of features that will go into a product. This is called a product backlog. This in itself could be considered a planning activity and may take the form of a collaborative meeting with the relevant people. Whilst it may not seem like planning on the surface, think back to how you write a project plan. Some of the effort involved in writing a project plan is to think about what is to be delivered. This is a similar activity. A product backlog looks at what features the product needs to have, before even a line of code is written. There is definite planning involved in this approach.
2) Sprint planning
This is the critical area of scrum where planning really comes into its own. If you assume a typical project with sprints that run every two weeks, sprint planning will take a full day of that. This is a significant amount of time on a project. Multiple meetings are spent simply looking at planning. Compare this to traditional project management where planning might take the form of a single meeting at the start of the project, and may be discussed for 10 minutes during a regular progress meeting.
3) The sprint backlog
Consider if you will the scenario where you monitor progress against your project plan. This isn't just a control activity, but it is also a planning activity. After all, if something is off schedule then you need to start making adjustments (or re-planning). The sprint backlog is a vital monitoring activity for the project; a way of measuring progress of the sprint and ensuring you are on target to meet your goal. If you are behind, things need adjusting, and again you are into a planning activity.
The perception of planning
As I mentioned earlier in this article, on more traditional methods of project management planning is a highly visible activity. It has a start date and a finish date and more often than not it even has its own phase in the project. Senior managers will know this activity is going on.
The problem comes when you are dealing with a client or a project sponsor who isn't keen on planning. Planning has become a negative word in the more fast paced competitive businesses of today's world. It is seen as too much talking and not enough doing. That is why managers are likely to favor a method which appears to show more of the 'doing' activities. Scrum does this. By early activity and early output, it appears to an outsider that scrum methodology shuns the task of planning.
This of course, is not true, as I have demonstrated. What scrum does very effectively is make planning an integral part of the overall project, to be carried out repeatedly, and collaboratively. This lessens the perception that work is on hold.
What can we learn from this?
There are a couple of points that can be taken away from this. Firstly, planning can be a bit of a political hot potato in many organisations, who want to see action on a project and may perceive planning to be non-productive activity. You can steer around this problem as a project manager by using the lessons of scrum. Make planning such a core part of your project that it becomes seamless with the rest of the activity.
The second lesson we can learn from this is that many organisations and individuals believe in the myth that scrum is anti-planning. Of course, this just isn't true. It is the opposite. It is pro-planning. It demonstrates that despite the benefits of scrum, many are choosing it for the wrong reasons. Planning is about getting things done right, not slowing things down. The reason scrum is so effective is because of the emphasis it places on planning, and the benefit this has on delivering not a quicker project but a higher quality project at the end of it.
Further reading - recommendations
A thorough book on Scrum, written by Ken Schwaber, one of the original architects of scrum