What are the Agile Metrics for Senior Management

Senior executives are more interested in “value realized” by the organization than the “value delivery” by the team.

Agile is not only the methodology to manage software projects, but also a philosophy to run a digital organization. More and more senior executives or cross-functional group leaders intend to learn more about Agile, besides major agile principles, what’re the significant details they would like to know? What kind of agile metrics the development team should track, that can be presented to leadership and has been a value add. Also, keep in mind, such tracking is not pressurizing the development team negatively, but for improving project success rate.

It depends on what the senior management really wants to see and the meaning they will derive from the metrics they are shown. As an idea, you could perhaps capture the number of defects raised for a given release; or you can start small and do this for a sprint. Perhaps you could give them data about the number of stories committed by the team vs. the number of stories completed. Perhaps you can capture the amount of time the team spends on non-sprint work that may come in the form of planned/unplanned meetings, production support issues, help needed from your team members due to their specialty that only a few others possess, you get the idea.

Typically the output of the team is 'added business value.' If you want to quantify anything, it should be that, because, at the end of the day, that's what counts. What it should not be if you use it, is the team velocity, be it in story points or user stories. That's a team's own metric, meant for the team to improve itself. Velocity is just a number and does not convey meaningful information beyond perhaps a trend that is only valuable if the team has stayed together for a considerable amount of time and will do so for the foreseeable future. The burndown charts are not entirely valuable especially if the underlying data is not kept up to date and more than anything it causes the team anxiety. Further, if the management starts comparing two teams together it could also be a disaster, sometimes you compare the apple with an orange. So, more importantly, present some ideas and elicit from them about what they want and what purpose would that information serve to them.

The senior leaders are more interested in getting an update about the measurement of the common business goals. Organizationally there should be common goals; this kind of common goals helps to create collaboration and cohesion between the "business people" and "the developers."  In many circumstances, having different goals tend to lead to differing priorities, communication breakdowns, and the growth of "silos."  However, at the team level, the team that is working together should come up with their goals in alignment with the organization's goals. The team should have autonomy in figuring out what works for them and what doesn't. They should then improve what doesn't work for them to make it work.

In most organizations, "value realized" is based on enhanced competitive advantage, and is usually measured in financial terms. These are usually increases in revenue/company valuation/user base or reductions in costs. What it really comes down to is an organization providing a culture that aligns its working with the Agile manifesto and just to name a few aspects – individuals, interaction, working software, collaboration, etc. You build a lot of trust and respect by letting people come up with what works best for them, even amidst some semblance of a boundary. For such an organization, no additional metrics are needed, but they are evident in the workings of that organization.

To put simply, senior executives are more interested in “value realized” by the organization than the “value delivery” by the team; they would more likely “scrutinize” the metrics from different angles, their intention is to ensure the healthy status of the project portfolio and overall project success rate; most importantly, they would like to understand the significant details and put them together to weave a big picture, and they want to become the change agent from doing agile to being agile.

Posted in: Agile,KPIs