There are people who believe that software development is pure art. And there are people who believe that it is basically manufacturing. The reality, of course, is that it’s somewhere in the middle.

Because of that, before you can even begin to measure how your team is performing, it’s critically important to understand your organization’s approach to development and how the teams are structured to maximize that effort.

“Finding good metrics, like flow metrics, end up being a balance between … do you treat what developers are doing as a manufacturing process? Or do you treat it more as a creative process?” said Jeremy Freeman, co-founder and CTO at Allstacks, providers of value stream intelligence software.  

Freeman referred back to the “Iron Triangle” approach to software development quality, which states that you can either develop things quickly, cheaply or at high quality, and everything between them is a tradeoff. 

This approach, he said, can also apply to flow metrics. 

Organizations can optimize more toward speed and predictability, or they can optimize toward data science and problem-solving. “These types of tradeoffs actually permeate all of your business decisions as technology leaders,” he said. “Do you focus on fixing quality? Or do you focus on fixing or shipping new features? And the flow metrics that are now a core component of the SAFe Framework end up having their own sorts of these ‘Flow Triangles.’ There’s your velocity, cycle time and team load. You always want to have really high-velocity routines. And that is intimately linked to how long it takes you to do things, and how many things are being worked on at once?”

Many high-functioning organizations have different teams working at different speeds, using different processes and tools, so coordinating that work is critical. “Thinking about flow metrics as a way to help make sure teams are working together is really important,” Freeman said. “If you imagine a team working on delivering a sprint goal, then you take a step back and think about how the collection of teams is working against shipping a major feature. You have to think about how fast things are getting delivered, and how that impacts your ship time. Are the levers you have to play with as a leader right? So these metrics are really helpful, and flow is really apt.”

Freeman recommends that organizations first figure out where their problems are, with the development team and all stakeholders. Then you can start measuring some coarse things around outcomes, and as you start identifying potential solutions, then you can get tighter and tighter with what you’re measuring. 

He noted that in talking to development teams, it seems like their biggest bottleneck is getting pull requests across the line. “There’s a high cycle time, no one will review my pull request, and that’s preventing us from actually shifting work,” he said. “In the pull request example,” he said, “maybe we’ll go from measuring your request cycle time to measuring how long it takes to get your first review, to know how long it takes you to actually complete any review cycle. And as you build those metrics up, you’ll actually get better information and start to pinpoint and solve problems.”