Gantt charts still have a place in the agile-verse!

 

Those of you who have followed me for a while will know that I value pragmatism over absolutism when it comes to delivery practices, tools and techniques. Pick the right tool for the right job should be a guiding principle followed by all project teams.

Easier said than done!

It is difficult when enterprise standards dictate a fixed tool set, but it is even more challenging when a company is undergoing a fundamental transformation of its delivery practices. When adopting new delivery frameworks it is tempting to embrace the bright, shiny new tools while branding those of the previous delivery approach as obsolete, but if we understand the context in which their usage will still add value we should still find a home for them in our toolboxes.

A good example of this is the use of Gantt charts by teams who are following an adaptive or agile delivery life cycle.

Although Gantt charts have been around since the early 1900's, just as with people, age is not negatively correlated to value. Tools such as burn-up charts provide an objective means of evaluating progress towards completing a release, but it is rare outside of pure product development contexts to find projects where a traditional representation of a schedule wouldn't also provide some incremental benefits.

This need could arise from any of the following causes:

• Complicated dependencies between the outputs from different teams
• Work streams that are delivered using traditional, deterministic life cycles
• Activities performed by supporting roles working outside of the agile teams

The project team will want to define the best way to combine the use of traditional and agile scheduling tools to avoid information duplication and inconsistency. Agile teams can continue to use their default tools, but traditional scheduling tools can be used to track other work which is not captured in the backlog yet still needs to be completed for project success.

If there is a need to have an overall integrated project schedule, the agile teams' sprints can be shown as a series of sequential fixed duration activities without the need to decompose those to any lower level. By reviewing burn-up charts, the exact number of such sequential activities can be adjusted to reflect accurate completion dates.

With significant change, there is a greater likelihood of success if you preserve valuable current practices when introducing new ones.