What is the Flow Framework®?
The Flow Framework® provides the blueprint for implementing Value Stream Management, connecting IT and the business, and transforming your organization into a high-performing tech company.
Surviving the Age of Digital Disruption
As startups disrupt every market and tech giants pull further ahead of entrenched businesses, the majority of enterprise IT organizations are facing an existential crisis. Either they quickly become much better at software delivery, or they risk becoming digital relics.
While technologists adopting DevOps and Agile have already made the transition, the gap between modern technical practices and the business has only widened in the process. A new approach is needed in order for the majority of the world’s organizations to thrive in this new age.
Introducing the Flow Framework®
The Flow Framework® was first introduced in Project to Product by Dr. Mik Kersten, and has since been adopted by IT leaders worldwide to bridge the gap between technologists and business stakeholders. The Flow Framework provides the methodology and the vocabulary to systematically relieve the bottlenecks that are slowing down software delivery and impacting business results.
Why a New Framework?
Numerous methodologies and frameworks exist for transforming, modernizing, and reengineering every aspect of your business. Some, like the Scaled Agile Framework (SAFe®), are focused on enterprise software delivery. Recent advances in DevOps practices address bottlenecks in how software is built and released. Other frameworks, like Geoffrey Moore’s Zone Management, address transformation from a business reengineering point of view. While DevOps and Agile principles have made a significant impact on how technologists work, they have been overly technology centric and have not been adopted broadly by business stakeholders. To bridge the gap, we need a new kind of framework that spans the language of the business with the language of technology and enables the transition from project to product. The role of the Flow Framework is to ensure that these business-level frameworks and transformation initiatives are connected to the technical ones. We need that framework to scale the three ways of DevOps – flow, feedback, and continuous learning – to the entire business. This is the goal of the Flow Framework.
Flow Metrics: Measure What Matters
Every IT organization gathers hundreds of metrics, metrics that typically measure improvements in process, productivity, quality, cost, revenue or adherence to standards. Yet all too often, leadership feels like it cannot see the forest for the trees, cannot see the full picture to make the right decisions. There is a gap in the ability to see the end-to-end performance of the software delivery organization and identify what is constraining the system from achieving its business outcomes. Flow Metrics fill that void, by providing a unique set of end-to-end metrics, per product value stream, that measure the rate of value delivery as correlated to desired business outcomes. Flow Metrics help identify and solve the system’s bottlenecks, eliminating inefficient local optimizations. They also provide a historical view of your performance, so you can understand how choices and changes impacted your flow.
Flow Velocity
How much value did we deliver?
Flow Efficiency
Do we know where our bottlenecks?
Flow Time
How fast did we deliver value?
Flow Load
Is demand impacting capacity?
Flow Distribution
Do we have business priority alignment?
Flow Framework FAQs
Flow distribution brings visibility to the different types of work that flow across the value stream. For example, one can see how many features are in progress compared to debt, defects, and risk items. Flow distribution helps people see where the emphasis actually lies from a prioritization perspective between the different demands on the teams. This is the beauty of Flow Distribution – people can see and understand the prioritization decisions of the different types of work over the time.
One could say that Flow Distribution makes priorities visible. Because a decision to do one thing is a decision to delay something else, having visibility on what’s not getting done is paramount. If a team needs to fix some technical debt, but ends up working on another type of work instead, then the prioritization decisions become evident, become obvious and this should provoke necessary conversations on important prioritization policies.
For more details, visit Tasktop's blog entry on Flow Distribution.
Flow Velocity tells us how many work items were completed over a given period of time. One can see how much work was completed week over week or month over month. Tracking the Flow Velocity trend over time provides historical data for teams to see their delivery rates. This can help teams improve estimates or forecasting for how much work they can deliver.
For more details, visit Tasktop's blog entry on Flow Velocity.
Flow Time is a measure of speed. Flow Time is the duration, the elapsed time it takes from when work enters the value stream to when it’s considered done. Tracking Flow Time helps teams become more predictable, because the data helps answers the question, “When will the work be done?”
For example, if measuring Flow Time over the last 60 days (say for defect work), results in 80% of defects taking three days or less to complete, we can use this data to get confidence levels. Given the defect data, we can say that the probability of finishing defect type work within 3 days is 80%. Flow time helps us to be approximately right instead of exactly wrong. If we estimate how long something will take by only looking at the average Flow Time (the 50th percentile), then our estimates will be wrong at least half the time.
For more details, visit Tasktop's blog entry on Flow Time.
Flow Efficiency is the percentage of time where work is in an active state vs. a wait state.
Much of Flow Time is actually wait time. Often, the emphasis for estimating how long the work will take to do assumes no interruptions or dependencies. Utilize Flow Efficiency to discover how much wait time is in the system. You are lucky if your Flow Efficiency is > 15% because 5% is more common. Measure Flow Efficiency to visualize wait time from bottlenecks so that your team can figure out how to reduce problems from wait time constraints.
For example, if the bottleneck lies in the validate state, then you can emphasize the need to validate work faster, perhaps by reducing the work-in-progress limit in the validate state.
For more details, visit Tasktop's blog entry on Flow Efficiency.
Flow Velocity and Flow Time impact business value. Delivering more business requests sooner (rather than later) boosts potential revenue increase and/or growth. Acknowledging and addressing risks reduces uncertainty as awareness influences necessary actions. Flow Load impacts happiness - people utilized at realistic levels of utilization can better focus with fewer interruptions, and this gives the work a chance to be completed with higher quality. Flow Distribution helps to ensure that quality and productivity stay high by addressing defects and debts which in turn improves retention. The ability to directly measure business results allows product teams to talk in the language of the Business.
There is evidence from reports like the “State of DevOps Report”, that happy teams (as measured in something like a Net Promoter Score) are more productive. People who are happy with their job bring enthusiasm, creativity and fresh ideas to the team, which in turn sparks improvements and innovation. We know that WIP is a productivity drain and that teams with too much work tend to be frustrated due to all the interruptions, context switching, and delays to finishing work. As such, one can use the Flow Load metric as a leading indicator for how workload is impacting the team’s happiness and productivity. Flow Load can also be used to influence WIP limits to help ensure the team continues to be productive.
Beware of comparing metrics between different teams and value streams. If the assumption is that Team A performs better than team B because Team A has fewer defects, then unintentional consequences can occur. The context between teams is often different. Perhaps Team B breaks their work up into smaller bits and delivers changes faster. Rewarding Team A because their defect fix rate is less, might actually be rewarding them for increasing batch size, which often delays delivery.
What we measure impacts people because people value what is measured. All metrics can and will be gamed based on perceived rewards. Decisions to reward fast flow time without regard for quality can result in faster delivery of low quality work. Rewarding for fewer defects might increase quality, but then impact Flow Velocity. It’s fairly easy to game a metric; therefore, it is important to measure the impact of the change in one metric on the rest of your other metrics. Keep in mind that all metrics are based on assumptions. All someone has to do to discredit a metric is to question the assumption.