Flow Metrics: Software delivery metrics for business leaders
There is no lack of data collection and visualization at our disposal. The problem is that, at the business level, there isn’t a comprehensive set of data that reveals how organizations are doing overall. Contrast this available telemetry with teams practicing DevOps who know their recovery time, their change failure and success rates, and their cycle times — all of which help teams identify opportunities for continuous improvement. So — how do we get this level of insight at the business level? The answer is Flow Metrics.
Flow Metrics, as 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?”
At the DevOps Enterprise Summit in London in June, I presented five flow metrics that can help you focus on desired outcomes at the company level — most notably revenue generation and revenue protection.
1. Things take too long…”When will feature X 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. Project N is the top priority…”Sorry, our team’s priority is to finish project Z right now”
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.
Throughout metric: Flow Velocity — how many work items 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?” Help others see the impacts of conflicting priorities across the organization.
3. Not in my project…”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) becomes neglected, as it gets 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 into four buckets:
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.
4. Shared services folks aren’t available…”It’s 6pm and we still haven’t started the one thing we needed to finish today.”
When people think they need to be busy all the time, utilization levels increase and teams become overwhelmed with too much work-in-progress (WIP). People utilized at 100 percent do not have the capacity to handle unplanned or urgent requests without dropping other high priority work. The single most important factor affecting how long things take is the amount of WIP, which is the primary factor of all speed metrics. If your teams are drowning in too much work, it’s time to measure WIP.
WIP metric: Flow Load — all the partially completed work in a value stream. Flow Load has the added benefit of being a leading indicator. Like a backed-up highway, you know your commute will take longer as soon as you get on the road.
5. Finding information…”So, what’s going on with…?”
We have more tools now than ever before. The reality of the situation is that everyone is busy working in their tool and each team uses a different tool. People have different views of the value stream depending on what tools they work in.
If I’m in Service Management, my view of the world might be in ServiceNow. If I’m in Portfolio Management, my view of the world might be in PlanView. If I’m in Development, my view of the world might be Azure DevOps. But there’s only one view of the truth and we constantly have to translate this in order to get our story straight. That’s often done via manual handoffs — spreadsheets, emails, and status meetings. If this sounds familiar, consider measuring efficiency.
Efficiency metric: Flow Efficiency — the percentage of time where work is in an active state vs. a wait state. Much of flow time is simply wait time. You are doing pretty good if your Flow Efficiency is > 15%.
Learn how much wait time exists in your value stream to drive the discussion around improving decisions on prioritization, capacity and utilization. When it comes to estimating how long things will take, if you measure anything, measure wait time.
How to get started with Flow Metrics
You don’t have to plan a big expensive initiative or get everyone’s approval before beginning with Flow Metrics. Start small. Here’s a list to get you going:
- Find one business leader willing to support a short (4–6 week) experiment in exchange for better visibility on what matters to them
- Identify one value stream to start with and visualize the flow of work
- Identify one metric (e.g., if your business leader’s pain point is speed, start with Flow Time)
- Develop one success criteria (e.g., faster flow)
- Improvement takes time — be patient and persevere
- Show and tell the results with business leaders and executives
Delivering customer value quickly requires the smooth fast and predictable flow of work across the value stream, which is why Flow Metrics can help you become the voice of reason in your organization. Flow metrics expose big picture business problems, in a language that business people can understand. Help your business leaders see the tradeoffs from decisions made and provoke necessary conversations for change.
Sign up for the Flow 101 Workshop
This two-day hands-on workshop shows you how to enable flow in your organization using lean practices. The workshop is best suited for teams engaged in Agile or DevOps transformations who are looking to leverage value stream thinking to make their transformations more successful. Flow 101 works best when attended by groups of different teams who are impacted by each other’s work. This gives teams the opportunity to discuss dependencies, workflow design, and priorities. Teams upstream and downstream from each other will work to make their work and their handoffs visible to each other.
Written by: Dominica DeGrandis
Originally published at https://www.tasktop.com on July 17, 2019.
