Don't focus on metricsMetrics must be used in service of a desired outcome.
What metrics should your team track to improve software delivery?
I hear this question asked a lot. And it is a pretty good question. But it’s not a great question.
You see, this question assumes that we need metrics to improve our software delivery. And while metrics certainly can be helpful in many cases, they aren’t always. And they should rarely be the starting point. Metrics must be used in service of a desired outcome.
The first step, before talking about metrics, should always be to determine your goal.
Let’s imagine you’re frustrated by how long it takes to ship new features to customers. You could start by measuring your lead time to changes. But that can be a lot of work. You have to make some decisions about definitions (e.g. when do you start and stop the clock?). Then you have to set up some instrumentation…
If your current lead time to changes is on the order of weeks, you don’t need a metric to tell you it’s too slow, or where to start making improvements. You just need to do a little investigation into why it’s taking weeks. Then get it down to days. Then hours.
Maybe at some point you’r lead time to changes will require rigorous measurements. But don’t start there.
Start with your problem. Then work on fixing the obvious problems. Start tracking metrics only when they’re needed.
Last summer, Dave Mangot joined the Adventures in DevOps podcast to talk about his similar approach to the DORA metrics with his clients. Have a listen.
If we don't use story points, how do we measure team effectiveness?
With respect to Goodhart's law, the DORA metrics are a place to start.
Introducing DORA the DevOps Engineer
How does your team do on these 4 key metrics identified as indicators of a highly-performing software team?
Audience question: What will be delivered when?
How do you create a plan for a team as to what will be delivered when?
Improve your software delivery