Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Flow efficiency: Big-picture metrics for developers

public://pictures/ben_wonson.jpg
Ben Wonson Senior Product Manager, Plutora
Yellow measuring tape and rulers on white background
 

Checking off the last item on a long to-do list always feels good. But when developers chase that feeling and become consumed with completing their own work, they often hold off on releasing tasks to the next person until they have checked off that last item. They are missing the big picture when it comes to resource efficiency versus system efficiency.

The truth is, measuring and monitoring how items flow through a system and whether things are getting stuck is just as important as is the efficiency of the individual pieces. Resource efficiency is the death of flow efficiency. It creates troublesome bottlenecks that can set an organization back, which can easily result in the loss of time and money.

It's better to use smaller batch sizes 

Batch sizes­­ refer to the amount of work someone has to deliver—designs, code, tests, etc. Large batches can give a developer a false sense of efficiency. That's why, when it comes to batch sizes, smaller is better. Smaller batch sizes allow for quicker feedback on smaller iterations of new features and capabilities.

Large batch sizes more often than not lead to a "starvation" of work in the testing or implementation areas of the value stream. In a large batch, the delivery of individual items is spaced out, which increases the cycle time for multiple items in the value stream.

When everyone is scrambling to get all their individual tasks done quickly before sending them to the next stage, it cuts off work to others, who are forced to wait but then suddenly get a large amount of work all at once.

It takes a community effort

While it might seem counterintuitive, increasing the efficiency of each contributor in a value stream may actually reduce the performance of the overall system. At the baseline, DevOps teams must stop thinking about individual efficiency and look at the organization's work as a collective. Time spent coding is fine, but it shouldn't be the main metric for the system, because it measures only individual output.

What are some better metrics? Managers can consider measuring cycle time, which looks at how long things are taking from start to finish. Aging is also a solid metric, since it measures how long something's been stuck at a certain stage. For instance, if there are things that are ready but haven't moved to the next mode because someone is waiting to add something else, aging metrics would spot that and allow for managers to shift allocations accordingly.

Another good place to start is to keep work-in-progress (WIP) levels low in each mode and reduce batch sizes in both the story size and the movement of items among modes in the value stream. A good rule of thumb is to make sure items move all the way to completion through the value stream before releasing new tasks to the same person.

Keep the big picture in mind 

Gaining visibility into the progress and status of the whole value stream is critical to thwart work starvation and achieve community effort. To improve the efficiency of a value stream, there must be a way to visualize and monitor the flow of tasks owned by the entire product team.

Using a value stream management platform can lead to greater visibility and control of every team, tool, and pipeline across an enterprise. Software delivery dashboards tap into value stream flow metrics, which demonstrate the rate of value delivery in relation to desired business outcomes.

In short, flow metrics allow businesses to view production through a wider lens and make stronger decisions. Flow metrics can also provide a historical analysis of performance over time. Software companies, specifically those focused on continuous improvement, must tap into value stream flow metrics in order to stay competitive.

Flow metrics can tell managers a lot about the organization's workflows, too. Consider a cumulative flow diagram (CFD), as illustrated in Figure 1. It illuminates how easily (or slowly) a task is progressing through a workflow. In this example, the area marked by red lines shows there is starvation of work from execution (yellow) to implementation (blue).

 

Figure 1. This cumulative flow diagram shows how a task is progressing through its workflow. In this case, the area marked by red lines shows a work starvation from execution (yellow) to implementation (blue). Source: Plutora 

 

Consistency is key

 

Of course, consistency throughout each mode or area is the goal—this tells a team that everything is flowing well and there are no issues with bottlenecks or work starvation. On the other hand, bulges represent inconsistencies and signal that tasks are getting stuck, not being completed, or not being passed on to the next stage.

 

Sometimes in a CFD, lines can disappear altogether if someone is not getting work from others or if there is someone holding on to batches of work. While the trend of the diagram never goes down (because there is always some progress being made), it highlights for project managers the areas to which they can shift their focus. By looking at the whole value stream in this way, project managers can synchronize their team's duties and have them working in tandem.

 

Many developers are unintentionally harming their organization's overall efficiency because they simply can't see the big picture. In this case, what they don't know can hurt them.

Keep in mind that a resource-efficiency approach will often lead to overall flow inefficiency. As the software development industry becomes more competitive and fast paced, it's critical for agile and DevOps teams to shift to a system-first way of thinking, rather than an individual approach, to optimize value delivery.

Keep learning

Read more articles about: App Dev & TestingApp Dev