My Ideal Agile Delivery Report
One of the biggest challenges, but also one of the most beneficial things a team can do, is shift from traditional style status reporting to a more agile approach which is focused on transparency and action-ability.
Too often, I see status reports that are multi page affairs whose main job appear to be to distract you from the information that really matters and provide the veneer of a well-managed project. They are filled with window dressing aimed to lull you into a false sense of security around how a team is going irrespective of the reality.
Quite often you will see a status reported of “Green — All proceeding well” even though if you were to ask anyone on the team how they thought they were going, they would tell you they were heading for a train wreck.
Most traditional reports that I have seen provide a raft of vanity metrics that help stakeholders feel good about where we are spending money and are not designed for action-ability. An ideal agile report focuses purely on potentially actionable information because everything else is waste.
With that in mind, I’d like to outline my ideal agile delivery report.
My ideal agile delivery report is both short (for ease of completion and consumption) as well as highly actionable. It consists of only 6 key pieces of data with very clear reasons as to why they exist.
Other reportable information should only ever be added if there is a definitive reason as to why it should be included, but also what types of decisions it will enable.
If you can’t act on a piece of information, there is no point reporting on it at all.
My Ideal Agile Delivery Report
My ideal agile delivery report consists of 6 key pieces of information.
These 6 factors drive specific actionable discussions around what I would argue are the most important factors of a team.
- A Release Burnup chart
- A Control chart
- A Team Health check
- Risks and Strategies
- A Budget Forecast
- Support & Incident metrics
Why are these 6 factors so important?
The Release Burnup chart
By far the most powerful piece of information a team can provide, this report provides real transparency on when a team really believes they will end. It provides clarity on both the scope of work a team thinks they need to deliver to achieve an outcome, but also the speed at which they can do so.
Because it provides clarity on these two factors independently it enables stakeholders and product owners/managers to focus on ruthless prioritisation of scope to maximise the impact they make in the time frame they need to, while also enabling team members to focus on how to get faster over time by eliminating wasteful activities and systematic change of how they work.
The Control chart
A control chart is the most utilised and misunderstood charts within the teams I’ve worked with. It is often overlooked and goes unused.
When used correctly however it is a key factor in establish a simple but resilient learning flow. By charting the cycle time of all work, and then focusing on the items that are the biggest outliers, a team begins to talk about the items that are the biggest impediments to flow. Over time discussing and resolving these factors not only speeds a team up, but it also increases the accuracy of the information a release burnup provides.
The Team Health check
The team health check provides a leading indicator of success for a team while also highlighting key environmental factors impeding their success.
Health checks focus on key indicators around the health of the leadership environment a team is operating in, the health of the intra-team dynamics as well as the health of the product they build.
When any key factor is low, actions should be taken to improve them.
Risks and Strategies
Unlike traditional Risks, Assumptions, Issues, Dependencies (RAID) logs, alignment on Risks, and the Strategies that will be used to address them increases the ability for teams to take action as things change. By aligning on the strategies a team will use rather than the specific mitigation plans they will put in place, a team is able to better respond to unexpected eventualities.
This generally forces a shift from a passive risk management approach via RAID logs into an active risk management approach via increased alignment, ownership and autonomy of a team.
Budget forecasts are critical for product teams. Due to the traditional split of build and run elements of most IT organisations, teams often ignore the importance of cash flow within the business. At its worst sometimes it feels like money grows on trees and budgets are an unnecessary hardship rather than a critical factor in building a successful business.
Forcing teams to both project and track budget enables team to begin to focus on managing a product team like a business. Based on a given budget, teams are expected to worry about the cash flow of their team and the deferring of investment spends to remain within budget (“profitable”). What this looks like for most teams, is that the discretionary level of investment spend allocated to a team allows them to consider what key investments they should make above and beyond the burn rate of their stable team.
The sheer scarcity of funding forces clear budget management within a team.
Support and Incident metrics
Clear information about open support and incident tickets, and their rate of resolution is the last piece of critical information a team needs. This information enables a team to understand the current supportability of their product. This in turn enables them to focus on balancing their efforts between building things for the future and making sure their product works for today.
6 Key Actions
When combined these six key areas of metrics cover six specific actionable items.
They help us make decisions around
- What will we deliver, and by when?
- Our biggest opportunities for improving the flow of work
- Leading indicators of success and the environment that creates them
- Risks and whether they are actively or passively managed
- Finite budgets ensuring teams focus on smart investment decisions around total cost of ownership and cash flow for their product team
- The balance between building for the future and supporting today