Agile is not Unplanned
Agile focuses on flexibility and the ability to change directions during the project, but it is not the same as working unplanned and rushing to do anything that comes up. For some people new to agile methodologies, this might be a bit of a surprise.
An experienced project manager, who at the time was new to agile processes, once said to me:
I thought Scrum was supposed to be agile, but the fixed sprints make it a lot less flexible than what I’m used to. When something new or urgent comes up, I can no longer go ask someone on the team to fix it.
At the time, I was mostly upset with the comment, but with some spacetime distance to the project I can now look back and learn something from it.
The first thing that was obvious was that the project manager was not at all as used to plans and following plans as he thought. Of course there had been project plans before, but only on a high level. There had not been the detailed plans that are prepared in a Scrum sprint planning meeting, where the team and the product owner negotiates a deal on what to commit to for the next sprint.
The second conclusion is that the project manager was not used to self organizing teams that do their own planning. In an agile project, the role of the project manager and product owner is to give the team a clear goal and then let the team work in the best way they see fit to reach that goal. To do that, plans are indeed required, but that’s a different kind of plans than the normal project plan.
Just In Time Planning
The key to understanding planning (and everything else) in an agile project is the term “just in time”. Agile is not without planning, but the plans are not done up front but rather done just in time for when they are needed. The detailed plan for a sprint isn’t done until right at the start of the sprint. The plan for the day isn’t done until the same morning when the team members pick whatever task is at the top of the to-do list.
This is the perfect strategy to eliminate waste. No detailed plans are done until there is an agreed specification on the work to do – less risk of wasting planning efforts on work items that are changed or removed. Just in time plans also have much higher quality as they are done with all the knowledge available at the time of planning. A traditional up front planning effort is done at the time when there is least knowledge of the project: right at the start of the project. Just in time planning allows all accumulated knowledge from the project so far to make it into the plans.
So if just in time planning is the key, what’s wrong with the project manager’s quote? If it’s just in time planning, why not just change the plans whenever anything new comes up?
There are two reasons to not go that way. The first one is respect for plans and for other people’s plans. In an agile project, when the project manager and the product owner have set the goal for the team, the members of the team have done their own plans. That plan is much more detailed than the project manager’s overall plan and that’s fine – the team has self-organized and planned, and the project manager doesn’t have to care about the details.
The project manager shouldn’t care about the details of the plan, but he must recognize and respect the fact that there are plans. He must recognize that changing any part of a goal that the team has committed to will reek havoc with the team’s plans.
This is really a part of servant leadership: paying respect to the people doing the actual work (yes, I just said that programming is the only actual work in a project, everything else is just preparation, although indispensable).
Being a servant leader requires understanding that, although being a project manager gives the authority to tell anyone on the team to quit whatever they’re doing and prioritize something else, that is often a bad idea.
A Cool Down Period
Another aspect to not allow the project manager and product owner to change priorities in the middle of a sprint is to force them to have a cool down period. Having to wait until the next sprint planning meeting forces the product owner and project manager to get their priorities clear. Everything can’t be the top, number one priority.
Agile is not Unplanned
It’s a common misconception that agile is unplanned, that agile is without architecture or design, that agile is without documentation. That is not true. What agile really does is to emphasize those activities and make them continuous activities instead of separate project phases.
It is not until it is natural to everyone involved in the project to treat plans (and the other stuff) this way that the project is ready for loosing up on the formal practices for planning.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)