Myths of agile: “there’s no planning in Agile”

I’m going to tackle some of the myths around agile software development. The first and probably most well known is that “there is no planning in Agile, you just make it all up as you go along”.

This is not at all true. In fact, I’m going to go out on a limb here and make an audacious claim:

Many agile projects do more planning than Waterfall projects. In fact, they may almost do too much planning. I hope any Waterfall people out there are coughing and spluttering their coffee all over their desks in response to that claim. Let’s pick this apart and explain why I’m saying this.

It’s not about plans, it’s about planning

One of my favourite quotes is this one, from Dwight Eisenhower:

“Plans are nothing. Planning is everything.”

This is a vital clue to understanding the role that planning plays in Agile Software Development. In Waterfall, the idea is for the project manager to draw up a big plan at the beginning of the project. Remember, scope is usually fixed up front, and from that, you can produce your Work Breakdown Structure, and from that, you derive your resources plan (who’s doing the work) and your Gantt chart (the order in which it is done). And from all those, you can figure out your costs, because those resources cost a specific amount of money.

Then, everyone signs off (we love signoffs don’t we!) on the big plan, and it is all agreed and locked down. Then everybody gets to work, following the big plan that the project manager produced. Well what does the project manager do now? Just bums around, reading Ars Technica? Hell no!

His job is to protect the plan at all costs. People will keep trying to move things around, add scope, shift times, swap person A for person B, delay this, delete that, switch this technology for that technology, and the project manager must, therefore, spend a lot of time:

• trying to stop all that from happening (because someone signed off the plan, remember? which means we can’t change it, remember?), and
• logging risks if he can’t prevent that from happening, to let the stakeholders know about the calamity that will befall the project from these unplanned changes.

This doesn’t sound like a fun situation for anyone, least of all the project manager. Why do projects get into such a pickle?

Waterfall projects commit to a plan when there is no information

Waterfall projects construct a large complex plan at the beginning of the project when there is:

• little or no information about the work
• little or no information about the product and how it looks and works
• and little or no information about external issues and risks (dependencies, competitors, partners, etc.)

No wonder that there are so many changes flying around on such projects. As information starts coming in, much of it conflicts with the plan, because it was based on incomplete information. That is, it was made up of guesswork, assumptions, and estimates.

This brings to mind another favourite quote, this time from a German general from a long time ago, Helmuth von Moltke:

No plan survives contact with the enemy.

Which we could think of in our context as: no project plan survives contact with the project. And that’s fine because we’re better off not trying to plan out the whole damn project from the beginning.

Agile projects plan repeatedly in small chunks

Agile projects (using Scrum or some variant of Scrum) don’t create one big plan at the beginning. They do lots of small planning activities (each sprint) that produce lots of small plans (sprint-long plans).

So at the beginning of a two-week sprint, you come up with a plan for the next two weeks: that’s called Sprint Planning. In this meeting, the team moves backlog items from the Product Backlog to the Sprint Backlog, and discusses how much they can complete and how the work will be done.

Rather than try and define a plan for work that isn’t really known or understood at all, the team comes up with a small plan for a small set of work that is:

Moltke, a pretty rad agile dude

• well known and understood (otherwise it will not be a candidate for going into a sprint backlog)
• able to be completed in one sprint (which is usually two weeks).

So you come up with a small plan for a small amount of work, then you do the work. Then you do the next plan for the next piece of work, and so on, over and over and over again.

Does that sound like “no planning” to me? No way. You will probably get a bit sick of planning when doing it this way.

Is such a small plan really valuable?

You might be thinking “but that’s a completely half-assed plan, it only goes for two weeks. The Waterfall plan was big and beautiful and had giant Gantt charts showing what everyone is doing for the next six months!”. Sure, but remember:

• the plan was largely made up since it was created at the beginning of the project. At a time when nobody really had any information about the project (since we discover information as we go along)
• the plan was created almost entirely by the project manager. A person who will be doing almost none of the work in actually building the product. Instead of by the team, who will be doing almost all of the work building the product
• much of the value is in the planning, not the plan.

Remember the Eisenhower quote previously.

The team gets together regularly and discusses the work, how much of the work they think they can do, how much there is still to do, which of it is looking more valuable than we originally thought or less valuable than we originally thought, which is turning out to be easier or harder than we at first thought.

These conversations are enormously valuable and help guide the developers and the product owner along the journey to completing the product or project.

Question: have you found agile to have not enough or too much planning?