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?
Latest Articles
Comments on all Articles
