Whilst Gantt charts can be useful in some project management contexts, they are often seen as too rigid and not well-suited to the collaborative, adaptable and value-focused approach of agile methodologies.
Following a summary of key reasons, I will briefly discuss challenges that are faced in more detail, often from senior management, followed by a compromise that is commonly followed that supports and delivers value.
To start with, let’s consider the problems faced with Gantt charts.
Gantt charts are typically designed for planning and tracking progress of projects with a fixed set of requirements.
With one of Agile’s strengths being it’s ability to prioritise in a flexible and adaptable manner. Gantt charts not well-suited in this environment.
Agile teams prefer to work with shorter sprints, often just a few weeks, which require constant adjustment of plans and priorities based on feedback and changing requirements.
Gantt charts, on the other hand, are notoriously difficult and time-consuming to modify on short notice.
In an agile organisation, the focus is on delivering value to the customer through working solutions, rather than meeting timelines.
Gantt charts are often focused on timelines and milestones, which can lead to a focus on completing tasks on time rather than delivering value.
Agile methodologies prioritise customer satisfaction, which is achieved through constant communication, collaboration and early delivery — simply put, a Gantt chart can sometimes get in the way of that.
Agile methodologies place a high value on collaboration and communication, with cross-functional teams working together to deliver value.
Gantt charts can sometimes limit communication and collaboration, as they can create a hierarchical structure that separates teams and functions.
Agile teams prefer to work in a more integrated way, with constant feedback and communication to ensure that everyone is on the same page.
Agile prioritisies flexibility, collaboration and adaptability. So in scenarios when Gantt charts are requested, stick to these Agile principles.
Focus on detail in the short term, without wasting time planning on the longer term in detail. The further out the plan, the less detail is required.
Gantt charts often assume that everything will go according to plan, when in reality this is rarely the case. Baselines are taken, against which the project is judged. Typically, you will only fail when judged against an initial Gantt chart, when it will almost certainly change throughout the project. So allow time for contingencies for potential issues to help ensure the Gantt chart remains relevant, even if unexpected setbacks occur.
Colour coding will allow you to indicate different types of tasks, or different prioritisation- where the focus should be. Visual colour coding will help everyone quickly and easily digest the overall Gantt chart.
Allow for team input, and avoid the Gantt chart being owned by a single person. The team owns the Gantt chart, and input from all should be encouraged. It should be a tool to help prioritise work, not simply a one-way reporting tool to senior management.
Rather than breaking down the project into tasks based on a timeline, consider using a value-based Work Breakdown Structure (WBS).
Break the project into smaller pieces of work based on the value they deliver to the customer. This will allow you to focus on value, a key principle of Agile.
Then prioritise tasks based on value. Using the value-based WBS, work on the most important and valuable tasks first, rather than just following a timeline. This will help meet the needs of the customer.
Consider Agile principles and work in short sprints to deliver working solutions. Look to constantly deliver value, rather than meeting deadlines.
If you are using a Gantt chart, you simply must update it regularly. Update it to reflect changes in priorities and requirements. Keep it aligned with the focus on value.
You will received challenges — especially from senior management who have been used to using, and almost expect, a Gantt chart. They will give you reasons why you should be using a Gantt chart, some of which are covered below.
Changing milestones
You will be challenged against changing milestones and delivering against the plan. But you must be clear that you are focused on delivering value in a changing environment and milestones dates will change — this is expected, and not a bad thing.
Resistance to change
Senior management may be resistant to changing from their traditional approach to project management, and may not understand how you can live without a Gantt chart.
It can be helpful to educate them on the benefits of an agile approach, such as increased flexibility, faster delivery of working software, and increased customer satisfaction.
Fixed timelines
Gantt charts are often associated with fixed timelines, which can be in conflict with the iterative and incremental approach of agile. These fixed timelines are not just the overall end date, but fixed timelines within the project — against which you are judged.
Senior management may be accustomed to having a fixed timeline for a project and may struggle with the idea of delivering value in more agile manner. So demonstrate continuous delivery of value, and explain how you should be judged against deliver of value, not delivery against a pre-determined timeline.
Lack of detailed planning
Agile methodologies rely on a more fluid approach to planning, which can be challenging for senior management who may prefer detailed project plans. This is particularly relevant to complex projects.
Explain that planning is absolutely undertaken — in fact all the time, every day. The difference being that fluidity is expected and change is welcomed.
So the focus on detail is for the short term, rather than completely end-to-end. Focus is where it matters.
Communication
Communication can be a challenge when working with senior management on an agile project. It can be helpful to keep them updated on progress, including regular demonstrations of progress, and to ensure that they are aware of any changes to the project plan as they occur.
It is important to keep communication open and transparent to help build trust and understanding between the project team and senior management.
To be Agile, the tools used should not be dictated, but rather chosen based on the needs of the project and the team. Agile methodology values individuals and interactions over processes and tools, so the choice of tools should be driven by the needs and preferences of the team, rather than imposed by external factors.
It can be helpful to have a discussion as a team to determine which tools will be used for communication, collaboration, tracking progress, and other key activities. The team should be involved in the selection of tools, as they will be the ones using them on a daily basis.
For example, if the team is working on a complex project with many interdependencies, a tool that supports visual mapping and planning may be more valuable than a simpler task management tool.
A roadmap is a visual representation of a high-level plan for a product or project, typically spanning several months or even years.
It is used to communicate the overall direction of the project, including key milestones and deliverables, to both internal and external stakeholders.
A Roadmap is a very often — and in my experience, always — a valuable asset to any project.
A roadmap can be a useful tool for communicating the overall direction and priorities of a project, and for ensuring that everyone is working towards a common set of goals.
So whilst it may not provide the same level of detail as a Gantt chart that people are often used to, it can help to provide a broader context for the project and guide decision-making in a more strategic and flexible way.
To finish off with, I want to address the questions that are often asked, and what should be asked, to determine the appropriate use of roadmaps versus Gantt charts.
Traditionally, within a command-and-control environment, the questions often asked are:
The questions that should be asked of a project in an Agile environment are different. And the tools and assets of a project should help provide the answers. The questions that senior management should be asking in an agile organisation should be focused on supporting the team, delivering value to customers, promoting collaboration and communication, measuring progress and outcomes, and continuously improving.
By asking these questions and supporting the team in these areas, senior management can help to create a culture of agility and innovation that drives business success.
To summarise, using a Gantt chart in an agile organisation can be negative as it may promote a focus on timelines over value, be inflexible to changes, limit collaboration, and may not reflect the dynamic nature of agile projects.
Using a roadmap in an agile organisation is better than using a Gantt chart as it provides a high-level, flexible view of the project that emphasises goals and outcomes over specific tasks and timelines. It encourages collaboration, flexibility, and adaptation to changing requirements, making it more suitable for agile projects.