Why Gannt Charts Are Useless For Agile Projects

gannt chart

What can you learn about your agile project from this Gannt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gannt chart? And how much value are you getting from it?

Hat Tip

Hat tip to Johanna Rothman, who doesn’t like Gannt charts, and who linked to an awesome article by Tate Stuntz, The Demise of the Gannt Chart in Agile Software Projects.

The Demise of the Gannt Chart

Tate starts his article with a nice statement about Gannt charts. Namely, Gannt charts work for manufacturing processes. In effect, he points out that they work because Gannt charts are good for optimizing systems with dependencies – and manufacturing processes have relatively immutable dependencies. Tate’s basic premise is that agile software development is so mutable, both strategically and tactically, that creating a Gannt chart of the process is both hard and of questionable value.

One thing I really like about his argument is the way he starts with an analogy to show the value of Gannt charts. He points out that Gannt charts are effective for managing projects with sequential dependencies (the argument applies to finish-to-finish, staggered start-to-start, and other types of sequential dependencies, not just finish-to-start dependencies).

He points out the obvious efficiencies of re-use and parallelism that can come from over-arching project sequencing. He uses the canonical house-construction model: build the foundation, then the other parts next. He also alludes to the argument that software development does not require this model to be in place. To reinforce that argument, consider pre-manufactured homes, where the walls may be constructed in advance of pouring the foundation – the dependency is severed.

Tate argues that agile teams sever these dependencies all the time. And he points to some elements of agile development that enable this – or arguably, are required if you want to sever.

  • Generalist team members. Generalists can re-sequence tasks within an iteration as they see fit. To quote Tate –

    “Well, if your Agile project goes like the ones I’ve seen, the team members will display the irritating behavior of constantly moving around to different tasks as seems most effective to them within the iteration – regardless of what you’ve written down.”

    And I agree, based on my experiences too. His argument is that the predictability that comes from using specialists comes at the cost of efficiency, due to bottlenecks introduced into the system. I don’t know if that’s true, from my own experiences, but it may be. I suspect that an optimized dependent/sequential system can be as efficient as a severed system. The point to remember is that agile is designed to deal with change, so change causes fewer cascading ramifications. It makes sense to argue that the dependent system is less efficient, given the presumption of change.

  • Pair programming. An interesting point about pair-programming is that it spreads knowledge throughout the team – making them modular. This modularity reduces or eliminates resource-constrained sequential dependencies. In other words, whatever tasks make the most sense to be done now, can be done by anyone who is available, rather than only the person who understands it. This is a variation of the generalist staffing model – but it is the practice that increases the generalizing nature of the participants.
  • Refactoring and Regression. Tate argues, as have we, that automated regression testing is critical to being able to change and refactor. This is a key tenet of continuous integration, something that every project should use, regardless of process.

A very interesting argument. Tate also cites Scott Ambler’s survey of agile adoption rates as showing that Gannt charts were the least-valued artifacts among agile teams.

Counterpoint

As interesting as Tate’s article is, the discussion in the comments is perhaps even more valuable. The comments vary from disagreement to nit-picking of points to agreement with the premise. There are some interesting ideas in the thread that end up augmenting Tate’s points, and also putting them in perspective (to prevent us from extrapolating).

  • Do some, but not too much, up-front planning. A few people touch on this, in the context of architectural work. One suggestion is for an architectural sprint to start the project, based on Poppendieck’s work. In practice, we’re at least guilty of this (if you disagree) or proponents-by-example (if you agree). More importantly, we think the “strategic view” is best explored shallowly in terms of requirements, prior to prioritizing what should be done in detail in each iteration. However, this doesn’t suggest that Gannt charts should be used. A roadmap showing relative sequence, without trying to manage dependencies may be more effective.
  • Emergent architecture versus planned architecture. One commenter points out that this is still a “dark art.” We would agree that making good architectural decisions before you know what you are building is much harder than after. But it gets back to an agile argument – you don’t actually know, even if you think you do at the time of planning what you are building. If we actually could know, then planned architecture would be better, and likely more efficient. But not necessarily more valuable. But to achieve that value, you need some understanding of the big picture. And a good approach to prioritization.
  • People generally affirm that detailed insight into the distant future is impossible. That’s why we have rolling-wave planning. Time spent on the uncertain future is wasted. A high level view of the future is not uncertain – you are defining scope and value. A low-level plan is uncertain. Gannt charts don’t provide useful dependency information at a high level, and the information at a low-level, in the distant future, is worth less than the low-level-tasks it sequences.

Conclusion

Gannt charts for the immediate term have a very high effort to value ratio for agile projects. Generalists manage dependencies, and change them, continuously. Updating the chart isn’t updating a plan for action, it is updating a tally of the score (of things already done). Not adding much value here.

Gannt charts for the long term have almost no value for high level activities. Dependency information doesn’t make sense for high level stuff. Gannt charts for low level tasks in the long term are also suspect, because we fully expect that the low level tasks will change. And therefore, their dependencies will change. So the work is throw-away work. Even worse, it implies a sense of predictability, or at least creates a false precision about upcoming work.

In short, Gannt charts won’t help you plan an agile development project. At least not enough to justify the expense of creating them.

Imagine you have someone good enough to create a Gannt chart, and keep it current through the change. This superman is also tracking and communicating those changes and effectively managing stakeholder expectations. Now imagine what other valuable things you could have someone that good doing. Where do you really want them investing their time?

17 thoughts on “Why Gannt Charts Are Useless For Agile Projects

  1. Thanks David, and as always, thanks, Roger. As a former mechanical engineer, I still have a fondness for lean, CPM, and other process analysis approaches. But I really liked Tate’s insight that mutable dependencies dramatically reduce the benefit of such an approach.

  2. I’m not sure I understand what you are recommending. Are you suggesting one shouldn’t schedule? I don’t get what the overhead is in a Gannt chart when it’s nothing more than a view in a Microsoft Project Schedule. I don’t use the Gannt view myself, but as far as investment above and beyond a normal schedule, it’s free.

  3. Hey Bill, thanks for commenting.

    I think scheduling is important. But maintaining a representation in MS Project of the individual developer tasks is too low level. I agree that if you have a representation of that stuff in MS Project, and you are maintaining dependencies for them, balancing the resource load for assigned tasks, and prioritizing them within each sprint – generating the Gannt chart from them takes no effort.

    My point is that doing all of that conceptual maintenance work is a waste of time (at that level of detail). The tasks and their dependencies are too mutable, the team will resequence on the fly. The team will introduce and remove dependencies faster than you can keep up. Tracking the higher level stuff (like which use case is being delivered, in which sprint) is more important, and will have a lot less churn.

  4. This is certainly an interesting view point. The agile and scrum methods make the ‘traditional’ planning often less important. However I would like to add following views:

    1.
    Planning in general, and gantt charts in particular, are an important ‘communication’ tool. I have found myself often creating a plan, just to be able to discuss it with team members, customer, users, suppliers, and so on. A plan should tell a story, it needs structure. After all, there is much more to the typical project than just the ‘agile’ programming part. You have users, trainings, installations, suppliers, and so. They need some timing synchronization to get to the end result.

    2.
    I don’t like the work breakdown approach: splitting up each task in more detailed tasks. Rather I work from the deliverables (so-called products in prince2 -speak). Unless the scope of your project changes, your deliverables remain fairly constant in your project. A gantt chart (or at least the left part of it) is the ideal place to explain that deliverable break down.

    We at TenForce have developed a pragmatic project management product that integrates with MS Project as a planning tool. We advice our customers to keep the planning on a high enough level, and not loose yourself in the details. Those get changed anyhow.

    Best regards
    Frans

  5. Thanks, Frans, for your insights, and welcome to Tyner Blain! I appreciate your comments!

    On the first one – I agree that Gantt charts are very powerful for communication, but only when they are made at the right level. A higher level Gantt is great for communicating to people external to the team. They aren’t going to get any value from knowing that Jim is writing the stored procedures to improve query performance on zip code searches on Thursday. But they certainly can benefit from knowing that we’re on track to delivering the address validation capability, which is a required predecessor of the instant loan-approval process.

    I definitely would like to learn more about how you drive stuff at TenForce – I’m sure our readers would like to know more too.

    Thanks again!

  6. Note to the previous commenter. I’ve removed your comment, just because you are addressing a comment to an individual in a tone I don’t care for. If you want to contribute to the discussions here at Tyner Blain, I’d love to have your inputs.

  7. It’s been a long time since you wrote this Scott but your points are still valid. A testament to your writing and clearly thought out argument I suppose.

    I note that you’re not saying that Planning is a useless exercise in Agile projects, just that preparing the traditional Gantt charts is a wasted dead-end effort. I could not agree with you more!

    So you might find it strange to hear that a lover of all things Agile would spend a few years in the closet building an online project management tool that looks remarkably like a Gantt chart, but I did.

    I really would love to hear your thoughts on it …

    http://blog.teameffect.com/post/Team_Effect_equals_Agile_friendly_Gantt_charts.aspx

    Regards,

    Jason

    1. The screenshot is gorgeous. What would be interesting to me is to see how it deals with “locking up” a resource for a period on the calendar (attending a seminar, vacation, etc), dealing with dependencies – where I think the real value of planning comes into play, dealing with changes to the tasks “in flight” and the backlog, providing a visualization of the value of the tasks and/or the value of a sprint/delivery,….

      Video is also really good (would be better with audio :)).

      Will think about it some more, maybe some other readers will find this old article and check out Team Effort and share feedback.

  8. Pingback: Graeme Foster

Leave a Reply

Your email address will not be published. Required fields are marked *