The age old problem (well for me a problem that has existed for the last two or so years) is how to fit Agile delivery into the wants and needs of a heritage waterfall process. This square peg and round hole are not easily solved.
Agile kinda works of the principle that you don’t know everything, but based on what you do currently know, you will work to ensure the customer gets what they want. This delivery method works well when you have a backlog that is constantly being reviewed and prioritised, a constant adjustment to ensure that the next sprint (or sprint horizon of two or three sprints) is able to accommodate the latest needs from the customer, the delivery rate is known and you can roughly predict based on historic data where (or how far) down the backlog you are likely to get within the constraints of the delivery timelines.
What is hard to square off is the requirement of the good old Gantt chart.
The Gantt chart give people the impression that the activities that are to be undertake by a project are known, that the length of time to complete the activity is also known, and, most importantly that everything will run without any delay and the beautiful Gantt chart will cascade through without issue.
Unfortunately (as many weathered project managers will know) this Gantt chart is not really worth the paper its written on. Its riddled with assumptions, dependencies and, more often than not, it is put together without having any idea of the full details of the delivery. It is merely a theoretical description of what might happen based on some experience that people have and a list of assumptions that is so long, people who pulled the Gantt together cant even fully articulate it.
BEFORE anyone who swears by Gantts hunts me down, let me declare that on large programmes of work, or suitably small projects, a Gantt DOES add value. Where a project is so HUGE it cant possibly be articulated as a backlog (due to sever complexity or similar) or where a project is so discrete and small, such that assumptions can be so well managed or have are mostly known, then a Gantt does help.
Through education of senior stakeholders I think that a well defined backlog, a few rules of the road regarding the PBI (product backlog items) and user community and a strong willingness to support the removal of blockers, a burndown or burn-up chart will have significantly more value than any Gantt chart.
The best an Agile team can do is depict the sprint profile and retrospectives. If there is willing then you could show when certain deliverables of significant business value are likely* to be delivered – but all in all, I don’t see a Gantt adds value to a team who do Agile delivery.
* likely – I use likely as the backlog is constantly being reviewed and reprioritised. If something of higher business value and higher importance comes up, this will most likely supersede the current schedule.