A common misconception when it comes to scrum is to do away with Gantt Charts. But Agile for Hardware embraces the use of Gantt Charts.
The thing with Gantt Charts is that they are inherently anti-Agile, its that they are so strongly associated with Waterfall planning that it’s difficult to separate the two.
However, Gantt charts are simply the most efficient way to organize and structure a complex project. The key to using a Gantt Chart in an Agile workplace is to recognize that it will change on a weekly, if not more often, basis. Traditionally Gantt Charts are used as an implicit “contract” between the development and commercial teams. It is the commitment that development makes to the commercial team about what will be completed and by when. Gantt charts are intended to be as close to fixed before the project even begins. Of course, this means that they are wrong as soon as the project actually begins. At its core Agile is a reaction to the facade of pre-planning and instead accepts the reality that 1) things change and 2) you can only plan accurately a few weeks out. Thus the key to using Gantt charts in Agile is to accept that they 1) are going to change and 2) will be detailed on the short term and become more generalized the further from the present.
The other major difference in the way to use a Gantt chart between Waterfall and Agile is in how the milestones are calculated. Traditionally the Gantt chart is filled out based on the sequence of activities and key dates. When the two don’t line up, it’s typical for the Program Manager to keet the end dates fixed and adjust the time allotted for tasks. However, in Agile there are two major differences: 1) project management needs to reflect priority, and 2) the time allotted for tasks is the fixed variable. An Agile Project Manager will structure their Gantt chart with the highest priority stories at the top. The overall flow of the project plan reflects prioritization, not milestones. In addition, when conducting project planning, the Program Manager keeps the story points (or time allotted) fixed per their team’s estimations and lets the completion milestones fall as they may. Of course there is never a perfect alignment between the projected completion milestones and the business needs. But instead of arbitrarily reducing the time allotted for various tasks in order to fit them all in, the Program Manager changes the definition of the release itself and the stories it contains, or the date that it will be delivered. The result is a much more realistic, accurate, and honest dialogue between the commercial needs, development Program Manager and the teams themselves. It is a acknowledgement that when there is a conflict it needs to be resolved.