Why the Gantt chart survived Agile

Agile was supposed to kill the Gantt chart. The Manifesto was signed in 2001, "responding to change over following a plan" became the line everyone could quote, and a generation of practitioners learned to treat the bar chart as evidence that a team had not modernised.

Twenty-five years later it is still on every executive's screen. That is worth explaining rather than sneering at.

The Gantt and the burndown answer different questions

A burndown chart answers: how much work is left in this sprint, and are we trending toward finishing it? It is a team instrument. It is honest, current, and almost useless to anyone outside the team.

A Gantt chart answers a different question: what happens when, and what is waiting on what? That is a question about dependencies and commitments. Your sponsor is not asking it to micromanage the team. They are asking because they have to schedule a marketing launch, sign a vendor contract, or tell a regulator a date.

No burndown chart answers that. No amount of Agile maturity makes the question go away.

Where Gantt charts genuinely deserve their reputation

The criticism is not baseless. A Gantt chart fails badly when it is used to claim precision nobody has.

The classic failure looks like this: a project manager decomposes eleven months of unknown work into 400 tasks, assigns each a duration to the half-day, links them into a dependency chain, and presents the result as a plan. Every one of those durations is a guess. Chained together, the guesses compound into a completion date with a spurious air of authority, and the moment reality diverges in week three the whole artefact becomes a lie that takes hours a week to maintain.

That is not a problem with the chart. It is a problem with pretending estimates are measurements.

Using one honestly

The version that survives contact with a real team looks different:

• Milestones, not tasks. Plot the eight or ten things that other people's decisions depend on. The team's internal sequencing belongs on the board, not the timeline.
• Plan to your horizon. Detail the next six weeks. Beyond that, show phases as blocks, not bars with end dates you cannot defend.
• Draw the dependencies, not the durations. The value of the chart is showing that the security review cannot start until the integration lands. That relationship is real even when both durations are uncertain.
• Show slippage rather than hiding it. A baseline that stays visible under the current plan turns the chart into a communication tool. Silently redrawing bars to keep everything looking green destroys the only thing it was good for.
• Update it on a fixed cadence. Weekly is usually right. A chart nobody trusts to be current is worse than no chart at all.

The honest summary

Agile did not defeat the Gantt chart because Agile never addressed the problem the Gantt chart solves. Iterative delivery is a way of managing uncertainty inside a team. Timeline commitment is a way of coordinating between teams, and between an organisation and the world outside it.

Most projects need both. Use the board to run the work. Use the timeline to tell everyone else what to expect, and be honest, on the chart itself, about how much of it is forecast rather than fact.