Five flow metrics can help you focus on desired DevOps outcomes at the business level – most notably revenue generation and revenue protection. What are flow metrics, you ask?
Flow metrics, as I presented at the DevOps Enterprise Summit/London in July, and set out by the Flow Framework, expose big picture problems to help you make better business decisions. Even better, flow metrics use a language that business people can understand. For example: “Only feature work got done last month – we didn’t fix any defects or technical debt. And that feature was delivered three weeks later than our biggest customer expected. So – what’s the probability that we’ll be able to deliver our next feature next month?”
[ Some people get confused about Agile vs. DevOps. We break it down: Read Agile vs. DevOps: What’s the difference? ]
DevOps metrics that work
Consider these five everyday problems that can be exposed by flow metrics:
1. Things take too long. When will the new feature be ready?
It’s hard to anticipate all the things that delay work. Uncertainty flourishes with every interruption from unplanned and invisible work. When people complain that things take too long, it’s time to measure just how long things actually take. Here’s where a speed metric is useful.
Speed metric:
Flow time is the elapsed time it takes a request (an epic, story, artifact, feature, whatever) to go from, “Yes, let’s do this” to “Done.” Typically measured in days, flow time can help you be more predictable because you can see how long features (for example) take to flow across the value stream.
This measurement allows you to look at percentiles and probabilities and answer questions like, “What’s the probability of delivering a new feature within 30 days?” The idea here is to be approximately right instead of exactly wrong.
2. Your top priority may be this project, but our team has another one
With so many projects happening at the same time, competition for people’s attention and resources is tough. Team A’s top priority is not Team B’s top priority. When priorities are unclear, people take on too much work-in-progress, and this increases flow time, causing delays across the value stream. A throughput metric will reveal just how much work is getting done.
Throughput metric:
Flow velocity can tell you how many work items are completed (usually viewed week over week). A decision to do one thing is a decision to delay something else. Flow velocity is useful for forecasting the number of features or stories given historical data.
And for asking, “Does flow velocity improve when there are fewer conflicting priorities?” It can help others see the impacts of conflicting priorities across the organization.
3. It may not be in the project scope, but we need to install important security patches!
When only feature type work gets approved, technical debt increases over time. Important non-functional requirements (“revenue protection” work) are neglected, overpowered by the promise of revenue generation. Important work morphs into urgent work as the neglected work evolves into an emergency, such as a security breach. If this is your situation, bring visibility to work type allocations.
Work type allocation metric:
Flow distribution via categorizing business value can be organized into four buckets:
- Features
- Defects
- Risks
- Debt
Visualizing these different types of work makes tradeoffs clear and helps decision-makers set the strategic direction for the company. Risks are primarily to tackle security/compliance. If you continue to do more feature work, you can’t expect that it won’t take away from doing risk work.
Either you’re managing your value stream or it’s managing you. Tech debt over time will eventually take you down. The business and IT need to understand this. Make sure you invest in your future by allocating capacity to fix tech debt.
