How can the Flow Distribution metric be utilized?
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.
How can the Flow Velocity metric be utilized?
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.
How can the Flow Time metric be utilized?
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.
How can the Flow Efficiency metric be utilized?
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.
What is the relationship between the Flow Metrics and Business Results?
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.
How does Happiness relate to specific Flow Metrics?
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.
Can/Should metrics be compared across value streams/teams/products?
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 betweens 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.
How do Flow Metrics drive Systems Thinking?
By their nature, Flow metrics are holistic in that they capture every dimension of how business value flows through the product value stream. This is in contrast to many metrics captured within Agile and DevOps which tend to be siloed (limited to just one portion of the value stream) or considered a proxy metric (e.g. how many folks have been trained on agile or automated testing). By looking at Flow metrics, it’s possible to optimize the entire delivery system rather than just a specific silo of activity (e.g. development or testing or deployment). The ability to see and think about workflow “horizontally” across the whole system leads to identifying bottlenecks where things slow down, stop, and/or sit idle. Product Teams can then work with their Value Stream Architect to determine how to remove or mitigate these bottlenecks to accelerate delivery and measure the results.
How do Flow Metrics drive Continuous Improvement?
Flow metrics provide a baseline to measure the current state of your value stream. This allows teams to analyze and propose countermeasures and other potential improvements which form the basis of experiments. After an experiment is run, the Flow metrics are used to help determine the impact. Successful outcomes benefit teams by providing direction for next steps and provide opportunities for other teams to learn and grow through the sharing of these success (or failure) stories across the enterprise.
Does the Flow Framework apply to smaller software organizations?
While Project to Product focuses a lot of its discussion on large-scale and complex software delivery, the Flow Framework™ can also be applied to smaller-scale software organizations. For example, some of the ideas in the Flow Framework – such as Flow Distribution and Flow Velocity – originated in tracking individual open source teams, from Mik Kersten’s work on Eclipse projects, to identify productivity bottlenecks spanning from the time that a user submitted an issue until a working solution was delivered. Regardless of the size of the organization, the goal of the Flow Framework™ is to ensure that metrics are tracked end-to-end to avoid the pitfalls of local optimizations of the value stream. (Rother et al., 1999)
Rather than focusing entirely on the time it takes a team to complete a user story (cycle time), the Flow Framework™ focuses on optimizing Flow Time, which is the time from when work entered the value stream (e.g. via an accepted customer request) to the time the software was delivered. Even in a small organization, this helps a team identify potential upstream dependencies (e.g. lack of UX bandwidth – User Experience Designers) that are the biggest bottlenecks to delivering more value to end customers.
In addition to these Flow Metrics, the product-orientation is relevant to any size organization currently tracking software delivery in projects. Even for a small startup that is engaged in professional services projects and product development, the pitfalls of project management can impede the ability to become a software innovator.
Note that for smaller organizations, some aspects of the Flow Framework™ are much easier to apply. For example, one may only have a single product value stream. And if you are a newer organization, there is a good chance that you are already product, not project-oriented. Additionally, the Value Stream Network will be much easier for you to create as you will have far fewer tools than a large organization. If that’s the case, you can move straight to tracking Flow Metrics. However, before you do so, make sure that you have all types of work captured by your Artifact Network, so that you are getting an accurate end-to-end picture of your software delivery.
Rother, M., Shook, J., & Womack, J. (1999). Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA 1st Edition. Cambridge, MA: The Lean Enterprise Institute, Inc.
What roles should consume the Flow Metrics and for what purpose?
While there are multiple roles within an organization that can benefit from the Flow metrics, the primary customers are the product teams and the Value Stream Architect. The Value Stream Architect primarily provides the systems level thinking to optimize the whole, (i.e. the flow of business value across the end-to-end product value stream) and works directly with the product team to identify bottlenecks and improve flow.
Executives benefit from seeing the product business results across the Product Portfolio to help guide investment decisions. Product Owners can validate the distribution of work across flow items and determine what’s appropriate for a particular product at a point in time. Product Owners can use Flow Load (WIP) to ensure the workload is sustainable and reduce negative impacts to team happiness and throughput (Flow Velocity).
How can the Flow Load Metric be utilized?
Flow Load is all the partially completed work – all the work-in-progress (WIP) floating around in the value stream. Flow Load is a measure to help organizations balance demand against the capacity of the organization. When demand is too high, Flow Load increases to the point where work sits idle, which delays delivery of features and hinders the team’s capacity to fix technical debt. Flow Load is the primary factor for all speed metrics. The higher the load on the teams, the longer work takes to complete. Utilize Flow Load to discover the impact too much WIP has on your speed metrics and your team’s happiness.
What is involved in doing value stream mapping to understand enterprise processes?
Value Stream Mapping is one important activity in the emerging practice of Value Stream Architecture. First, organizations need to realize that the way value flows through a Value Stream Network is defined by its delivery teams, tools and processes. Next, Value Stream Mapping can provide an initial understanding of the high-level flows through that network. The main caution here is not to try to make the flows and maps linear, as that’s a common reflex and a problematic over-simplification when diagramming or whiteboarding. Software delivery is a complex collaboration network that produces intangible assets through conversation, coding and cooperation between numerous specialists. These lines of collaboration form a complex network which needs to provide flow, feedback and traceability. Once this network and the flow has been defined, it’s time to start moving on from a whiteboard exercise and understanding the ground truth of the Value Stream Network. That’s where concepts like the Flow Framework™ and Value Stream Architecture come in.
Are there any ways that AI and other analytic techniques are being used to improve the ability to make sense of enterprise processes?
Not currently that we are aware of. Organizations need end-to-end models of their value streams to be defined to pursue this, as data in any specific tool, such as an Agile tool, is an insufficient training set to provide much beyond training for how to do local optimizations of the value stream–yet another pitfall.
How does value stream mapping compare and contrast with other automated business process mapping techniques for making sense of enterprises processes like process mining, and process discovery?
These approaches should be highly complementary. Organizations can apply the Flow Framework™ in support of re-engineering their company’s operating model around digital innovation. It’s critical to connect any Value Stream Mapping and Architecture activities to what’s happening on the business transformation side, and to do those activities in lock-step.
How does moving to a Product Model impact traditional Project Management Office structures?
The PMO (as traditionally defined) was needed to provide visibility to the “black box of IT” that is inherently needed in a project model but is one of the major advantages addressed with moving to a product model. The alignment of business and IT addresses from a product perspective the 7 areas noted in Table 2.1 in “Product to Project, (Budgeting, Time Frames, Success, Risk, Teams, Prioritization, Visibility) many of which were done in a traditional PMO.
Moving from project to product is a journey, so organizations which have a Project Management Office will need to evolve into a leaner PMO as the product model is rolled out (starting small and then moving into a scale and sustain phase). During this journey, items such as how to transition annual funding into a more agile product management funding structure which includes aligning product team size and also the utilization of Flow Metrics to drive business decisions, could be addressed by a centralized organization structure. The organization structure is secondary to ensuring that Systems Thinking can be done to ensure that the objectives noted in Table 2.1 in “Project to Product” are addressed across an enterprise.