Communicating Project Progress

We have been working on a large state project that has chosen to use an Agile SDLC. Two challenges I’ll discuss today are:

• Stakeholders haven’t been trained in agile.

• Tools for communicating agile progress are poor.

  
  

Stakeholders and communication

The project I’m currently working on has struggled with coordinating the work of multiple agile teams. We are using the Scaled Agile framework (SAF) and one area of difficulty has been communicating the “schedule” to outside stakeholders. While these people have extensive experience managing large government IT projects, many of them have no experience managing or providing stakeholder support to an agile project.

There are things about Agile projects that make managers nervous:

• Working software is prioritized over documentation, and people are prioritized over process. Managers at all levels want the benefits of Agile, but have to understand that they should not expect the documentation and the rigorously defined processes – particularly at the project manager level – that they are used to on a waterfall project. This is an underestimated change for managers moving to Agile

• Scope can change, as agile projects will learn from the customer and adapt as needed. With changing scope, you have less predictability in the schedule.

• There is no Gantt chart. For many government projects, the Gantt chart is the foundation and standard for communicating traditional waterfall project progress.

  
  

These managers need training and a “change champion” to help them understand agile, and to set expectations as to how stakeholders should be participating and measuring the progress, given an agile approach.

Tools for Communicating Agile Progress

As mentioned above, in an Agile project, there is no Gantt chart. I have yet to see a corresponding agile tool that tells managers a) here is how we are doing, and b) here is when we expect to be done. This is particularly visible on large projects with multiple project teams.

Let’s compare the processes.

Condensed description of a waterfall project: W-team gets together, decides on scope, builds comprehensive design doc and project plan describing the scope, schedule and cost. The project plan - usually in the form of a Gantt chart – is provided to stakeholders based on their need.

Condensed description of an agile project: A-team gets together, decides on scope, builds backlog of stories, assigns stories to epics, and epics assigned to program intervals (PI). With a tool like Jira, dashboards, burn-down charts, and other reports are given to stakeholders, and estimates of when the project will complete can be drafted, along with a corresponding cost.

One of the problems with the waterfall project is that the Gantt chart is only a predictor of future performance. Since most IT projects are not duplicates of previous projects, and the teams assembled to staff the project have not worked together before, the estimates for duration and effort are imperfect. The Gantt only gives the illusion of control and predictability. However, it is what government agencies have used for decades to communicate plans and progress.

But Agile - when it comes to providing project status to stakeholders - is in no better position. There is no standard report or mechanism to show stakeholders project progress. And adding fuel to the fire is the agile mantra that with each sprint, customer feedback will be factored into future development, basically stating that the current “plan” will change tomorrow, as the scope is dynamic.

Managers running an agile project will need to work with stakeholders (up the chain) to find acceptable ways to communicate “the plan”, and to ensure stakeholders understand how to read and interpret these new communication tools. Additionally, managers will need to train scrum masters and agile teams (down the chain) to provide adequate inputs/forecasts needed to assemble the components that make up the agreed upon way of communicating “the plan”.