Agile is not Unplanned

Agile focus 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, that at the time was new to agile processes once said to me:

I thought scrum was supposed to be agile, but the fixed sprints makes it a loss less flexible than what I’m used to. When something new, 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 understand 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 allow all accumulated knowledge from the project so far to make it into the plans.

Servant Leadership

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 play 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 preparations, 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 a cool down period. Having to wait to 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.

  • Pingback: When should you use Agile? | agileinsights on 2013-09-03
  • Pingback: This Month Can be a Project | Personal Project Management on 2013-09-17
  • Henrik Yllemo on 2013-09-02

    There is a massive difference in the way that a reactive leader and a proactive leader respond to agile methodologies. I would say agile is allot about trusting the team members and allowing the team to grow from experience. That includes making mistakes and failures as well as success. Point being that a reactive leader is easier to identify, but a proactive leader may undermine the teams growing process by servant intentions.

  • Murray Robinson on 2013-09-21

    Thanks for this article. So many people think that agile means no planning and yet this is totally false. I think the Scrum evangelists have a lot to answer for this misconception. I will e writing some posts about the role of project management in agile on my blog.

Software Development is a Job – Coding is a Passion

I'm Anders Abel, a systems architect and developer working for Kentor in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

The complete code for all posts is available on GitHub.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.