Partner-Blog ALM Works #DWSC20
Gantt Charts that Work for an Agile World
Der Digital Workplace Summit by Communardo The #DWSC20 by Communardo will take place from November 3 - 5. For this conference ALM Works has written this article as a partner blog.
Das ist ein Beitrag von ALM Works als Teil unserer Partner-Blogs zum #DWSC20.
Many agilists would argue Gantt charts are a relic, the project management equivalent of a historical artifact. Yet they're still extremely popular — even in organizations with Agile teams, where they may be an awkward fit. But what if Gantt tools were adapted to support Agile practices in Jira? What if the timeline and dependency visualization of Gantt charts could be coupled with Agile project management methods? Here’s how.
How Gantt got here
When Henry Gantt first published his bar charts in the early 1900s, they were considered state-of-the-art. By listing tasks on a vertical axis and then showing the schedule for completing those tasks on a horizontal axis, project managers were able to help their teams more easily visualize the overall project at a glance. For wartime and industrial-age projects, the Gantt chart became a popular tool for ensuring massive projects were completed on time and on budget.
Project, program, and portfolio managers (collectively referred to as project managers) have pushed the evolution of the Gantt chart over the last 100 years. The original Gantt charts had to be laboriously redrawn every time the schedule changed; the move to software obviously opened the door to major improvements. Managers could more easily add additional information, like project completion percentages, task assignments, and elements indicating the relationship between tasks.
Gantt charts also became a common tool to help project managers easily explain the status of important projects during board meetings. Management became skilled at reading Gantt charts and noticing “tent-pole” tasks that were extending project deadlines and troublesome “pre-reqs” that were causing delays. Unfortunately, Gantt charts sometimes told only part of the story and project managers were left trying to explain important details without having the necessary data readily available.
Kanbans and Waterfalls
In 2001, 17 software development practitioners developed and published their Agile Manifesto.
While the benefits of iterative and rapid development had been around for decades, the Agile Manifesto brought the concept of Agile software development to the mainstream.
The Agile Manifesto is rooted in four stated values:
- Individual interactions over process and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
As you can imagine, the only message many project managers paid attention to was, “no process, no plan, no documentation.” And the thought of losing those three control points caused them to break out into a cold sweat. Their livelihood was rooted in controlling projects. Even the Project Management Institute (PMI) highlighted “control” as one of its five phases of professional project management.
Despite that early resistance from project managers, Agile methods started to take hold. At first, it was a grassroots effort using Scrum meetings and Kanban boards covered by a rainbow of sticky notes.
Gradually, project managers started seeing elements of Agile creep into their project management software. But a large percentage of project managers couldn’t figure out an effective way to incorporate Agile methods into their five-phase, Waterfall approach to managing projects. How can the scope change when the CIO has already signed the requirements document?
What followed was a period where confusion and conflict reigned in software development shops all over the world. Project managers were continuing to develop plans and schedules and reports based on a Waterfall approach and software development teams were holding their own Scrum meetings, creating Kanban boards, resisting documentation requests and recommending scope changes during development and testing phases.
Fortunately, as collaborative software developers like Atlassian came up with better ways to present data in a hybrid (Waterfall/Agile) way, project managers started to adapt.
They began to realize they could still create and assign tasks, they could still have a high-level schedule in place and they could still follow a general software development lifecycle (SDLC).
Additionally, they started to see the benefits in following an Agile approach. Best practices started to evolve very quickly at this point and project managers started demanding even more integration from their tools. But it was proving difficult to find the right mixture of Gantt-like visualization and Agile flexibility.
Agile Gantt is the next evolutionary phase
Gantt charts have always been an outstanding way to visualize entire projects. From the work breakdown structure (WBS) to assignments to scheduled completion dates, the Gantt view is superior. But as Agile user stories, sprints, Scrum meetings, and Kanban boards grew in popularity, the once-favored Gantt chart got lost in the mix. Because it had limited contextual data, it lost some of its magic.
Then ALM Works and a handful of other vendors created the next evolution in Gantt technology, Gantt apps built for Jira.
ALM Works' version of these Agile-oriented Gantt charts is called Structure.Gantt — a Gantt-style project timeline with dependencies and resource allocation highlights, built on top of the Structure for Jira app.
The key idea is to take the foundational benefits of a Gantt chart but allow Agile teams the ability to view, manage, interact, and revise their project plans within that project timeline visualization.
For example, an Agile-oriented Gantt tool can couple the chart with sprint planning. In an Agile environment, tasks are often assigned to a specific sprint, vs. a specific date. In Structure.Gantt, project managers can use sprint dates for manual scheduling of tasks — so tasks can be scheduled to begin and end based on sprint dates.
An Agile Gantt timeline, adapted to reflect sprints instead of calendar dates
What’s more, since teams are often assigned several tasks that all need to be completed during a sprint but in no specific order, managing the workload for those teams has long been outside the reach of traditional Gantt charts. Structure.Gantt solves this problem with a fixed-duration task management feature. As tasks are assigned, the workload for each task is divided evenly across its duration, allowing project managers to quickly identify and address overloads or opportunities within each sprint.
Of course, no Gantt solution could truly be called Agile if it required a ton of work to build a useful chart (we’ll leave that kind of chart-building to those old-school PMs!). Using the Agile Gantt Chart template tool in Structure.Gantt, project managers can create charts with Agile Planning enabled in just a few seconds. These charts can be customized to display the hierarchy that best fits their business needs:
- Stories only
- Stories beneath epics
- Portfolio (requires Atlassian Portfolio to be installed), with initiatives above epics
Agile-oriented Gantt tools, such as Structure. Gantt, provide project managers with the necessary tools to get the most out of an Agile methodology, while allowing for the scheduling realities that are imposed on their projects by business-related deadlines, market competition, and budgetary constraints.
In fact, the manner in which Structure. Gantt integrates data from standard Jira data sources will become the new normal. Project managers will increase efficiency, reduce errors and improve overall product quality while experiencing the maximum power of the old and the new.
To learn more about Agile Gantt, contact Communardo and ask them about Structure for Jira and Structure.Gantt.
