Should You Use Gantt Charts in Agile Project Management?

The topic of Gantt diagrams in the context of Agile software development has been a much-debated question. On one hand, there are those who claim that using Gantt charts and trying to stick to them during the Agile lifecycle is likely to bring you about as much success as burning down your entire office building would… Then, there are those that claim that “true” Agile is about using whatever works; if Gantt diagrams seem to work out for you, go ahead and use them as you see fit. Also, there are the realists who say that 100% true Agile is still rarely used. Most companies rely on some form of custom hybrid process instead, which could benefit from the transparency that Gantt charts can bring.

Sure enough, Jeff Sutherland banned Gantt charts when he first implemented Scrum in 1993, and has claimed even over a decade later that he didn’t see much reason to change this. Still, a growing number of companies seem to be using these diagrams, and we’re seeing more and more development tool vendors implement a version of Gantt charts in their tools.

So let’s investigate the topic further: how exactly can Gantt diagrams be beneficial in the management of Agile projects?

Gantt charts in Agile software development

Gantt diagrams are bar charts that illustrate project schedules and help visualize the start and end dates of any process. In the context of Agile software development, such charts are used to illustrate releases or sprints.

As simple visual representations of the progress made against estimates on any activity, process or project, Gantt charts can greatly facilitate communication by bridging cultural or geographical differences. Since these diagrams are easily understood by all parties regardless of language or expertise in Agile software development practices, they are useful tools when trying to collaborate with, or report on their progress to several teams and departments across various regions.

That said, it’s true that Gantt charts are of limited use in the classical sense of Agile development. The primary purpose of using Agile is to enable developers to react to changing requirements faster. As requirements change, the effort and time needed to address the changes, too. Therefore, in order to adequately represent and visualize the total amount of work left, Gantt charts would have to be updated almost continuously. Quite obviously, this would be an unnecessary and unrealistic burden on your development team.

Therefore, in the case of a single team working on a single product, updating Gantt diagrams is either a needlessly overwhelming task, or one that’s simply forgotten about. Either way, it’s safe to advise against their use in such a development environment.

So when should you use Gantt diagrams?

On the other hand, a growing portion of software projects is way more complicated than that. Rather than seeing a single team working hard on a product with a short turnover time, you’ll find several geographically dispersed teams engaged in the development of complex n-tier system architectures. In the case of IoT product development, for instance, managers will try to orchestrate the parallel development lifecycles of hardware, software and service components. Some of these will use Agile, while others will rely on a more traditional approach (generally Waterfall or V-model).

In the context of enterprise-grade scaled Agile development, planning encompasses longer periods, and multiple teams using different methodologies to collaborate on a complex “system of systems” end product. Gantt charts can greatly support such higher-level planning by visualizing how each development stream relates to the others in time, and, to a limited extent, can even represent relationships between them.

The management standpoint

Therefore, from a program management point of view, using Gantt diagrams in system of systems development does make a lot of sense. Even if the chart is just regularly, rather than continuously updated, it helps provide insight into project progress to higher management, who might not be familiar with burndown charts and would like to oversee the overarching product lifecycle, rather than individual development streams.

Burndown charts are still considered the go-to solution on the team level, and could also help management interpret the Gantt chart. But Gantt diagrams are indeed legitimate Agile tools from a project management standpoint, and could greatly help higher management understand and oversee the progress made against estimates.

As an advanced application lifecycle management tool, Codebeamer offers interactive Gantt charts to help you visualize and efficiently manage your releases and sprints. Not only does it provide statistics and a great overview of the project’s progress, but they also allow you to edit your releases directly from the diagram via a user-friendly drag and drop functionality. Any changes done on the chart will automatically take effect on the affected releases or sprints.

Searching for the best Agile ALM platform for your needs?

Using the right tools can greatly simplify Agile project management. But what factors should you consider when trying to select a tool for managing your software development lifecycle?