I’m going to tackle some of the persistent myths surrounding 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.
One of my favourite quotes of all time 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) to deliver that scope. And from all those, you can figure out your costs, because those resources cost a specific amount of money.
Then, everyone signs off (yay 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:
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 construct a large complex plan at the beginning of the project, when there is:
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 (i.e. it was made up of guesswork, assumptions, and estimates).
This brings to mind another favourite quote of mine, 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 (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:
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 start getting a bit sick of planning when doing it this way.
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 two points:
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?