PM-Fu: Why Gantt Charts Are Useless in Agile Development- and How to Make Them Useful

September 17, 2007 – 10:19 pm

The Tyner Blain blog posted a while back on Why Gantt Charts are useless in Agile Development.  They’re right on many levels- I personally struggled with this early on in working with Agile Development.  I know many PMs do.  Every PM should read this, whether or not they’re working with Agile Development.  It applies just as much in a business environment that adapts and changes to business needs as it does to Agile Development.

At the same time, Gantt Charts *can* be used in Agile Development.  Like in Agile Development itself, it’s all about adaptability.

The key is to learn to build your project plans in a modular way.  Within every project, even an Agile Development project, there are some tasks that simple must depend on one another and must be completed in order to complete a given goal.  To meet a specific business requirement, for example, you know that you need to develop function X, Y, and Z.  You know you must write requirements, you know you must write test plans, you know you must test, you know you must release them.  If you intend to deliver a complete solution for this business requirement within a single release, then that’s your module.  The number of iterations within that module, the order within that module, is not as relevent as the fact that you are going to do all of these tasks, and must do all of these tasks, in order to deliver a solution this business requirement.

So now that you understand something about a project ‘module’, how do you manage with it?  Try these steps:

1.  Develop your project’s task list as normal.

2.  When you create your project plan, organize your task list into modules.  Assign modules to software releases according to your current estimate as to what order that these things will be delivered in.

3.  When your project team, or your management team, shifts, then shift the modules within your project plan.  This WILL sometimes wreak havoc with your plan, particularly levelling and dependencies.  You will learn ways to adjust so that it’s easier (I could give pointers here, but really, I’ve learned that it’s heavily dependent on your style of PMing).

4.  Communicate, communicate, communicate!  You will need to constantly put out updated projections and updated task schedules when doing things this way (Agility does not come without a cost).  Your team must always know what’s coming next, so that the preparation work needed for it can be ready (for example, requirements for the next phase of development must always be ready before the developers finish the current phase).  Your management must always know how the delivery dates change, so that they can manage to the new schedule.

There is more to it than this, but again, it’s heavily dependent on your management style, and so your mileage will vary a bit.  Once you get used to it, it’s extremely effective- think of it as “Planning to not have a plan”.

By planning your modules carefully, and watching your dependencies to always keep the right ground work queued up, you can be ready for anything.  Your team will be ready to change directions on a dime, and be truly Agile.

There’s a saying I heard in a college psychology class that has stuck with me for life- “The most flexible part of a system controls the system.”  In the business world, the most flexible company in a market is capable of controlling the market (just look at Apple and Google).  Planning for Agility is tough- get used to it.  If you can pull it off effectively, you have a massive advantage.

Like this post? Buy me a cup of coffee.

  • del.icio.us
  • Digg
  • Reddit
  • Slashdot
  • StumbleUpon

  1. 2 Responses to “PM-Fu: Why Gantt Charts Are Useless in Agile Development- and How to Make Them Useful”

  2. Great article. I do think that anything that helps an agile team communicate externally is good. A couple questions about modules…

    1) What are you organizing into modules? Is it use-cases or other immediately-value-enabling collections-of-stuff? Or is it the work breakdown structure for a sprint (define d in some other way)?

    2) When you add the module to your project plan, are you adding the next level of detail below it? In my experience, the utility (or maybe the ROI) of this is inversely proportional to the complexity of the project.

    3) How do you address leveling, when either a)you only track modules, which are multi-person, or b)you track the WBS, which an agile team will self-manage into different individual assignments within the sprint.

    Thanks again!

    By Scott Sehlhorst on Sep 18, 2007

  3. Thanks for the feedback Scott!

    Regarding your questions:
    1) I organize all of the tasks necessary to build the particular piece into the module. This means business requirements, use cases, code, QA time, everything. I leave my dependencies in place- for example, the release of the functionality in the “module” to production has a dependency on the completion of the release that the module is going to be included in. It creates a little overhead for me to do this, but as you said, it helps the agile team communicate where they are.

    2) I add the next level of detail below it. For reasons why, see above- it lets me hook in the appropriate predecessors when needed. For example, in our environment, development items go to QA, UAT or production in bundles of these “modules”. By having a task for QA, UAT and production release, I can drop in the predecessors hooked to a master “deploy to ” task for that release.

    3) This is where art meets science for this. If your team is dedicated resources, you can simply level by modules. Otherwise you have to level by WBS.

    By Stacey on Sep 18, 2007

Post a Comment