Metrics that matter - or might at least

I've been thinking a lot about how to help align management behaviors to support organizational Agility. I think - still trying this in the real world - that our best chance might be to use the existing structures of incentives with some tweaks to the content.

We have Job descriptions, success factors, and personnel reviews at our disposal. I might think that those things are impediments to becoming our best selves and yet they prove super durable, so I've been working on how to use them to create a more supportive environment.

I'll spare you my apple seed planted on a table top analogy...

For this post I want to talk about organization level metrics that might lead to a better environment and appear hard to game via bad behavior.

1. How many layers of communication are between the user and the team implementing a solution for that user? The ideal number is zero as shown below, each additional communication point reduces the fidelity of the message.



2. Average number of projects each person in the organization is working on. One is ideal. When we assign people to multiple projects we essentially abdicate our responsibility to prioritize the goals. It's ineffective, inefficient, and unfair to team members.

3. Number of projects in flight organization wide. Just like teams and individuals, organizations benefit from limiting work in progress. When we focus on a small number of items we can increase the flow rate - projects get done - and maximize return while having less of our budget at risk.

4. Number of production deployments over time. The point of tracking this against management is to encourage smaller more independent releases reducing execution risk and realizing value earlier.

5. Equipment delivery lead time. Almost everything we do requires some sort of equipment. It could be a laptop for a developer, a VM in a private cloud, or the ability to drop a container into a cloud service. Whatever it is, wait is waste. We want to encourage reducing that wait time through the most appropriate means available. It might be automation, negotiation with vendors, or moves from owning to renting.

 

6. Percentage of capital budget allocated. In my heart of hearts I am a cash accounting kind of guy AND the finance folks don't care about my heart of hearts so we are stuck with capital budgets. The more money we have tied up in work in progress the more risk we carry. Every week a project goes without a production release accumulates risk; every production release resolves that risk. We might not like what we have but we know what it is and how much we've spent. We want to encourage frequent risk resolution events (production releases).

7. Percentage of time set aside for learning and improving current work. People need time set aside to learn and to improve their own work processes. We want to make that explicit as part of any transformation.

8. Hours of manual work. By manual work, we mean repetitive manual tasks. This is the kind of work that can eat a lot of time and also drains people of their creativity and energy. Eliminate it, automate it, just don't ignore it.

9. Number of inter-team dependencies. This is a count of the teams you must coordinate with before deploying your code to production. In a perfect world you would have total freedom to deploy non-breaking changes whenever they’re ready.

10. Number of after hours calls and emails. People need time to refresh and sending after hours work emails sends the wrong message. If we need 24/7 coverage, we must staff for it.

I am hopeful that giving transformation managers something to measure that makes the environment more supportive of agility will be a useful and effective lever in the work we do. Please share your thoughts with me on twitter at @mikeonitstuff

PLEASE NOTE - These graphics are from a stock service for the most part and the one about deployments is problematic. If you created any of them, let me know and I will happily credit.

Thanks for reading -- Mike