In this article, we would like to showcase that it’s possible to have a Gantt chart representation with Agile (in its Scrum variant) ways of working without jeopardizing Agile practices. That might sound impossible. There is a long-standing case against Gantt charts in Agile communities. Gantt chart is so "old world", the waterfall totem, the first soldier to fall at Agile D-Day. So Gantt charts cannot be Agile, right? Actually, that’s not completely true!
The case against Gantt charts
To be honest, that’s more how Project Managers do with them that make Gantt not Agile at all. The worst fallacy of a Gantt chart is to pretend to be an accurate representation of the reality. Again, that’s not the fault of the chart itself and it’s not the Project Manager fault either. It’s the consumers of the Gantt chart that create this fallacy. Just because the representation is simple, people who are reading the chart think it’s how things are actually going. And who are the readers of Gantt chart ? management, customers, etc the people who are the least in contact with the nifty details of the work.
Gantt chart is all wrong
That’s plain false. Things always start before, ends after, update of progress is as mad as Windows progress bar. This representation is easy to understand : teams are doomed to update every little details, dependencies, tasks.
And it’s not even the worst part. Not only the representation of the current state of the work is wrong and generates a insane amount of bureaucracy but the projection part, the Roadmap is equally bad. Why that ?
Mainly because of the very fundamental way of working of a Gantt chart. You need to define a start date and an end date. Both precise day. And to have an end date you need to have an estimation of the amount of work. But as estimation are almost always false, that means that end date is likely to be wrong too. But Gantt chart still impose to commit on a precise day.
The Agile rise
And guess what? Agile methodologies came out partly to fight this bureaucratic and micro-management of product development to focus on delivered value:
- Coarse grain estimations (t-shirt size, fibonnacci or no estimate at all) to fight endless discussion whether this precise task you will do in 6 months is really going to take one hour or two.
- Focus on User Stories (and not tasks) to deliver a fully functioning slice of working software.
- Having metrics and that focus the value delivered to customer instead of focusing on tasks completion. Like user story burn-up chart.
So we now have an Agile backlog, organized on business value with high level estimation (or no estimations at all). Customers are happy because what matters is delivered in priority. Product team is happy because they no longer have to maintain indicators that that have no value for them. Product Management is happy because the new indicators focus on what matters. The ability of the team to execute (burn-down chart, velocity charts) and what is delivered to customers (burn-up chart).
Everybody is happy ?
No! Higher level management is not. Because they lost a precious tool they were understanding (even if the tool was broken). They don’t understand those new tools. They lost the ability to foresee “by themselves”.
Can we make people happy ?
So, in this kind of articles, this is where the author try to justify the burden of “user stories with start-date and end-date”, “tasks estimated in hours” because management needs it.
Ready for something different?
Think about what people (customers, management, etc) are looking for on a Gantt chart?
- where team is heading?
- where are you right now?
- is there any roadblocks?
What do we need to create an agile roadmap?
The good news is that you can provide all this, in a form of a Gantt chart, without compromising with your Agile values and practices. Let’s recap what do we need to render a Gantt chart:
- First, dates: a start-date an end-date to draw the bars,
- Then, a sense of progress: the inner bar to indicate the completion,
- And, optionally, dependencies (does something needs to be done before something else ?) and children (how something is broken down)
Where is the information ?
And guess what, we already have everything in our regular Agile backlog!
- Dates: a user story doesn’t have dates per see but they are planned in a sprint or a release. This sprint or release do have dates isn’t it? Let’s re-use this information to draw the bars!
- Progress: depending on team practices you already have a sense of progress. For instance some teams keep track of a “remaining effort” on their stories. It’s what is used to draw burn down chart. If the remaining effort is compared to initial effort, we can compute a percentage of progress. Otherwise, if the team went do not estimate stories, we can still compute that ratio by comparing the number of closed task versus the total number of tasks.
- Dependencies can be set with a link between two stories. But in an agile world, we tend to stack things by priority (first things done first).
There is a dedicated article if you want to learn how to build an agile product roadmap in your project.
To summarize, Epics are planned for Releases and Stories for Sprints. You can see on the picture that the epics dates correspond to the whole release. Same for stories, you don’t have the detail on when exactly the work on the story started and finished but that doesn’t matter. What matters is that the story was completed by the end of the sprint or not.
The last point is important to understand that displaying tasks is the root of all fallacies in a traditional Gantt. Gantt is actually quite good (even if traditionally too rigid) at giving a high level view of things. As you start to goes into details (tasks duration and assignments) it naturally drives to micro management. Instead of having management focused on the delivered value, they will focus on “Why John did take 2 hours to complete this task in may ?” or, even worst “Are we really sure all staff engineers are charged 125% ?”.
Wrap up
So can a Gantt chart be agile ? It sure can as long as drawing it doesn’t influence the way the Agile team work. The line is thin and this is where the tools can really protect the team. With Tuleap this line is drawn with Roadmap tool that is a representation of what’s happening on the product backlog. The teams continue to work following Agile practices, their management can have a representation they understand but without the micro-management temptation. The best of both world !