Flow Measurements Can Eliminate Bottlenecks in Development

Only 8% of what’s planned by agile teams is delivered and 20% of features are canceled after code has been written.

Those findings come from value streams collected by Tasktop Viz, a value stream management platform company founded and led by Mik Kersten. Kersten added:

• 35% of products have zero capacity for new work for 12 or more months; and
• 85% of products under invest in security and debt

These are problems that could be identified and fixed by measuring flow, Kersten told an audience Wednesday at DevOps Loop, a virtual conference held by VMware Tanzu. 

“While we might have very agile teams, there are heavyweight processes, both downstream and upstream of those development teams,” Kersten said. “Of course, this results in slower velocity, much longer time to value in terms of what we deliver, and a lot of frustration across our teams.”

Meanwhile, other organizations have mastered delivery, he said. The question then becomes: How can DevOps ensure that organizations can innovate at the pace of a software company to deliver value to customers.

“To do that, we actually need to understand where the bottleneck is,” Kersten said “Where does value slow down? Where are developers getting frustrated? Where are we having most of our incidents come from?”

To address the bottleneck challenge, Kersten created the Flow Framework, which was the focus of his discussion Wednesday. Originally presented in Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, the framework is designed to provide the language and methodology to “systematically relieve the bottlenecks that are slowing down software delivery and impacting business results.”

First, it helps to know what “flows” in software delivery. What flows are features, risks, defects (usually pulled by customers) and technical debts, Kersten said.

The Flow Framework outlines flow metrics organizations should monitor to detect bottlenecks in software development:

Flow velocity — how many flow items were done over a specific unit of time.  “Flow velocity is a very important metric that just tells us — forgetting story points, forgetting the details of every user story, or issue or defect or incident — how much flow happened across a period of time whether that was a sprint, a month, a fiscal year, a quarter — anything of that sort?”

Flow efficiency tells DevOps where the process is waiting. It’s the ratio of active work days to waiting states, so that a project that is 10 days in the active state but 30 days in both active and waiting states has a flow efficiency of 33%. 

“Wait states are the kiss of death,” he said. “Basically, where are we thrashing? Where are things impeding us from getting work done, flow time is just the end-to-end time for delivering value, but it’s end-to-end — it’s not how long it took from code commit to code deploy.” 

Flow time is the time work takes, from when it starts in design to work completion and all the waiting states — such as waiting for approval, waiting for dev work to be done, waiting for triage — in between. 

Flow load is the amount of load on the value stream. ”It’s a work-in-progress metric, but that spans teams, and it shows how much load is on the team,” he said. If a flow load gets too high, flow velocity actually slows down and flow time gets longer because “we’re overloading the teams and thrashing happens,” he says.

Flow distribution is simply the distribution of features, defects, risks, and technical debts. Flow distribution may vary — fast-moving consumer-facing applications might need fast feature flow to do AB testing, while another app may need a slightly slower feature flow but very fast flow for risk management and security, he said.

Together, the flow metrics make up the value stream. 

“So every value stream should have its flow tuned to the flow distribution needed for the business outcomes,” Kirsten added.

These metrics can be mapped to the business results in value, cost, quality and customer happiness, according to the flow framework chart.

Organizations may even know where their bottlenecks are, but the Flow Framework provides a way to monitor and prioritize improvement, Kirsten explained.

He shared an example of an unnamed organization that knew self-service testing was a bottleneck, but once they prioritized improving it and measured backend self-service testing, they found that by accelerating features, they unlocked 45% of the capacity that had been there but was getting stuck in the bottleneck.

“They were able to actually pull $150 million in their business cases in delivering on those roadmap items,” he said. “It’s exactly the great thing about measuring flow in this way — it gives you this way of connecting investments in platforms, APIs and infrastructures, and new services and cloud to business outcomes.”