Agile plans

One of the books I have going at the moment (I tend to multi-task books) is Mike Cohn’s Agile Estimating and Planning, a fairly concise take on how to obtain these qualities from agile projects.


I think that the central allergy of agilistas is to the Gantt chart, that famous diagonal artform of ribbons and spilling arrows. The Gantt chart is notorious for its inflexibility in practice and in giving a false sense of certainty.

Yet, despite the central messages of agile methods pointing to the ability to pivot the project in response to customer contact, planning is still a part of the process. It’s just wrapped up in low-precision formats.

Currently in A Discipline for Software Engineering I am working through Chapter 3 on planning. Here are the 4 “general things you need from a plan”, according to Watts Humphreys:

  • Job sizing: How big is this job, and how long do you expect it to take?
  • Job structure: How are you going to do the work? What will you do first, second and so on?
  • Job status: How do you know where you are? Are you going to finish on time and are the costs under control?
  • Assessment: How good was your plan? Did you make any obvious errors, what mistakes should you avoid in future, and how can you do a better job next time?

All these questions don’t just apply in the PERT-and-Gantt world Humphreys came from — the IBM mainframe and DoD universe. They’re also answered by agile practices:

Plan requirement Agile practice
Job sizing Planning poker, story points, ideal days
Job structure The planning game, backlogs
Job status Velocity, burndown charts, kanban boards
Assessment An infinity of blog posts 😀

Burndown charts, coming from the Scrum methodology, have a companion in Humphrey’s world of the Earned-Value chart. You might think of EV as a more elaborate version of burndowns, with all the good and ill that entails.

Similarly, planning poker can be seen as a cut-down version of the Wideband Delphi method introduced by Barry Boehm. Pair programming can be seen as a kind of code review. And so on.

Truly, there is nothing new under the sun 😀

This entry was posted in PSP, Software Engineering. Bookmark the permalink.