Status Reporting for Agile Organizations

Raise your hand if you LOVE reading (or writing) status reports!

Beuller? Bueller?

Nearly everyone I’ve ever met has a love/hate relationship with status reports. They’re not fun to write and certainly not fun to read, but how else is leadership going to get a pulse on what’s going on? Every organization going through an agile journey should always question those necessary evils and ask ourselves “is there a better way?”.

Do you believe the status reports at your company? If your answer is "Well......", there's definitely some opportunity to improve. I find in many orgs, one of the following is true:

• Most projects are listed as green. In theory, this should mean everyone’s on track! Things are peachy! But is it true? Does everything get delivered as expected, with high quality and delighted customers? Probably not. Often these are “watermelon” projects - they’re green on the outside and red on the inside. Maybe there’s a better way.
• Most projects are listed as yellow. This is often the case when some aspect of a project is on track, but other aspects are at risk, or people can’t agree on the color. As a PM, I used to cover my butt by listing my projects as yellow most of the time, that way if (or when) things did go off-track, I could point to all of those weeks of yellow status. Maybe there’s a better way.
• Most projects are listed as red. Underpromise, over deliver; that’s the motto of lots of organizations. But does that really help leadership understand where to dig in further and help? Maybe there’s a better way.

Let’s get back to basics and think about the goal of status reports. Yes, the purpose is to understand status of where the teams are and if they’re on track, but let’s dig deeper. Leaders likely have four goals when it comes to status reports:

• Has what we’ve built so far been successful?
• Are we on track?
• What is the team working on next?
• Where and how can I help the team be more successful?

Status reports have traditionally tried to answer these questions by comparing where we are now to where we thought we’d be when the project started. Considering the Cone of Uncertainty in any project, you can see start to see where status breaks down. We’re comparing all future status reports to where we thought we’d be when we knew the least.

There is a better way!

Let’s revisit the goals of status reports and consider solutions to each of those:

Has what we’ve built so far been successful?

We can qualitatively see this by going to team Sprint Reviews or Demos to see real working product and feedback from users. We can also measure this quantitatively. Consider helping teams create the right metrics to answer these questions. First ask what success looks like in your organization. Is it a happy customer? High quality product? A happy team? Fast delivery? Predictability? Specific outcomes for our end-users? In reality it’s probably a little bit of all of these, so encourage teams to start measuring the ONE THING that’s most important and then add on low-overhead metrics to make sure they are balanced. If we only ever measure how fast a team is going, quality will likely suffer. If we only ever measure customer satisfaction, team happiness will likely suffer. Balancing multiple metrics will help us see the whole picture and where we likely need to put a bit more effort. Here are a few example metrics that I’ve seen teams use:

* Note that Team Velocity is NOT a metric listed - this is purposeful because velocity is a great metric for teams to use to forecast, but often a detrimental metric for leaders to assess teams!

Are we on track?

Remembering the Cone of Uncertainty above, make sure you're not trying to compare where we are now to where we thought we'd be at the very beginning. That said, it's still good to answer the question "are we on track for the next incremental release?". Burndown charts can be very useful to answer this question. The first question to ask is, are we operating against a fixed date OR fixed scope? If we're trying to do both, quality will suffer (this will be the subject of a future post). If we have a fixed release date, great! We expect scope to shift based on what the team can actually get done and the burndown chart will help us figure out how many backlog items won't make it into the release (or how many can be added if we're ahead of the game). If we're fixing the scope, no problem! The burndown chart allows us to extrapolate our actuals to determine the most likely date we can go live with that fixed scope. The beauty of burndown charts is that they help us figure out these adjustments early, not right before the release, so we have more flexibility on tradeoffs.

What is the team working on next?

All agile teams should be forecasting what’s coming up, but often new teams are so focused on the current work that they aren’t thinking about future work. Forecasting helps set expectations with customers, makes dependencies easier to manage and fosters tradeoff conversations earlier rather than later. As teams focus on becoming more predictable, their forecast accuracy will increase, but forecasts should always be considered plans, not commitments. We want to allow for feedback every sprint and that feedback will often change the forecast.

Where and how can I help the team be more successful?

The ultimate leadership question! I find this is better suited to a conversation than communicated in a status report. My favorite solution to this is a weekly risk checkin. At a government client in Australia, we implemented this for the team of teams working on one product. We had a ROAM board that people would add any risks or concerns, then weekly, we’d do a quick standup with senior leaders on any new risks that were added, how they could help and reviewing any actions from last week. It was an amazing way for leaders to get involved, help the teams and for all of us to have regular, honest conversation about how things were going.

We CAN make small, incremental changes to how our organization operates to be more effective. Status reporting is one of those areas that is often ripe for change. Experiment with these ideas in one part of your organization and see how it goes, then adapt. The challenge is to take some of these ideas to

• help your teams decrease the amount of time they spend communicating status and
• make the status updates you do get more useful.

What one thing can you do next week to make your status reporting more effective?