“Too much WIP is the enemy of productivity,” – Dominica DeGrandis, author of Making Work Visible, and Principal Flow Advisor at Tasktop
The happiness and engagement of the people who plan, build and deliver software has a direct correlation on the productivity and quality of their work. Combined with the rise of burnout in IT staff, it’s not surprising that there’s a renewed focus on ensuring teams are not being overburdened with the digital demands of the business. After all, you want the people who best understand how to create through software to be empowered, healthy and motivated. Flödesbelastning is an important measure in that respect – as well as the key to understanding problems in both Flödeshastighet och Flödestid.
Flödesbelastning measures the number of Flow items being actively worked on in a value stream, denoting the amount of WIP (work in progress). If the total number of items being worked on (either in an active or waiting state) in a value stream is too great, there will be a negative effect on output. Tracking Flödesbelastning shows changes in Flödeshastighet och Flow Time, showing the business the point at which taking on too many flow items at the same time reduces output.
Excessive Flow Load can be correlated with inefficiency. As Donald Reinertsen emphasizes in his book The Principles of Product Development Flow – when WIP is high, queues are high. By tracking Flow Load, you can set it at a level that maximizes Flow Velocity minimizes Flow Time – such as increasing workload for seasoned teams working on a mature product value stream, but reducing it for a smaller team on an exploratory product.
Flow Load in Action
One software company observed that Flow Time for defects was too long. This directly impacted the Flow Load, with the organization identifying a high defect load across a three week period. Flow Time to repair was long and the happiness of both users and testers was at risk. The Value Stream Architect examined the underlying factors and found the bottleneck. They found the longest wait state was in “code review.”
Working with the Engineering Lead, they decided to initiate a trial whereby they release low risk defects without a code review, while maintaining the process for more complex code changes. They then monitored the reopen rate to see if it had a negative before doing it at scale. Flow Velocity went up, Flow Load went down (ensuring teams didn’t burn out from context switching) and Flow Time was reduced (from 22 days to 11 days over a two-month period).
A Deeper Drive into Flow Metrics
The Flow Institute offers a range of courses on the Flow Framework and Value Stream Management.
In this on-demand course by Dominica DeGrandis (bestselling author of Making Work Visible) introduces the Flow Metrics, providing a deeper dive into what they are and why you need them. The course explains the theory behind Flow Time, Flow Velocity, Flow Efficiency, Flow Load and Flow Distribution.
Measure what matters in software delivery…
Traditional organizations have no real form of measurement that can tell organizations if investments in their digital transformation are working – until now.
Flow Metrics—from Dr. Mik Kersten’s the Flow Framework®—provide business and IT leadership with a critical window into the enigmatic world of enterprise software delivery.
These business-level metrics provide a common language between business and IT so you can make collaborative decisions around software delivery to achieve innovation velocity.
- Learn more about each Flow Metrics
- Measure what matters in software delivery
- See real-life examples of Flow Metrics in action
- Begin your journey from project to product
