I am having lots of conversations these days about executive dashboards for Scrum…what does a leadership team really need to know in order to do their job well, and how can teams provide that information without wasting valuable of time preparing reports? Within these discussions, there are also nuances such as: what agile metrics might actually be dangerous to share with management because they can drive unintended consequences? And what metrics should or shouldn’t be linked to incentives?
With these debates as a background, I am embarking on a regular series of posts to explore the subject of agile metrics and leadership dashboards further. For this, I will be drawing specifically on experiences setting up our own dashboard at Scrum Inc. and working with a large tech client (who shall remain anonymous) to set up an agile executive reporting tool for their C-suite leadership. I welcome everyone to join in the conversation and share your own experiences, both positive and negative, in the blog comments. I will try to weave these into future posts.
To start, what are the goals of a leadership dashboard? Like a good user story, it is important to have a clear vision of the desired outcome, and a set of acceptance criteria so that you recognize success when you see it. Particularly if you are using agile to develop the dashboard incrementally, you need to know when your latest increment is “good enough.”
At the most basic level, leaders need to accomplish three objectives:
- They need to establish and maintain a compelling vision that aligns the organization around a shared sense of purpose.
- They need to maintain visibility of how the organization is progressing toward the realization of that vision, and make course adjustments as needed to ensure progress.
- They need to support motivation and accountability within the organization.
An effective leadership dashboard directly supports the second objective, but its can also help deliver the third objective, and should be informed by the first.
To my mind, a successful dashboard should provide leaders with the relevant context and metrics they need to make informed decisions. It should be updated on a frequency that meets or exceeds the required decision-making cadence. Finally to the extent possible, the dashboard should be assembled from data that teams are already collecting to inform their own process and pulled automatically to minimize distraction from producing valuable new product.
Relevant Content
I will definitely revisit the topic of potential metrics to include in a dashboard in much more detail in future posts. For this discussion, suffice it to say that top-level metrics should answer the key questions of:
1) Are we producing the right product(s) for the customers we are trying to serve;
2) Are we prioritizing our efforts and applying our resources correctly given what we think we know about the market and our competitors;
3) Are we making consistent progress towards our strategic goals; and
4) Are we doing all of the above in a way that we can sustain for the long run?
Metrics that answer or inform these questions help leaders make better strategic decisions. Extraneous metrics are at best a distraction, and at worst cause leaders to make bad decisions.
Update Cadence
Some decisions only need to be made once a year, such as “should we renew our annual contract with…?” Others need to be made monthly, daily, or in response to real-time events, such as “how do we restore service given an outage that just occurred?” A truly great dashboard provides the current snapshot of key metrics with the most relevant data being shown. Real-time decisions need data from a few moments ago, whereas monthly financial decisions are better made with the recent month’s complete data rather than a partial view of the current month’s results. Deliberately matching update frequency to decision cadence brings the most powerful data to the right place with the least amount of effort.
Automation
We speak with far too many teams that complain about the onerous reports they are asked to produce for senior leadership. The typical complaint is that leadership wants updates on a number of metrics the team never uses for its own purposes, so this data must be gathered, calculated, and presented manually. The team sees this as a huge waste of time to produce metrics that don’t even reflect reality on the ground.
The Scrum process throws off enormous amounts of high quality data, such as velocity, team happiness, planned backlog, defect and impediment lists, and business value. Most teams already collect this data in software tools with API interfaces. Other than the first few iterations of a new dashboard where the metrics and presentation are still being refined in coordination with leadership stakeholders, there is no good reason dashboard data can’t be pulled, calculated, and presented automatically.
As I mentioned, this is just the first of many posts on this topic. If you want to dig deeper, feel free to check out our past online course on "The Agile Leader's Dashboard".
-Alex Brown
English 
French 
Spanish