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.
For more details, visit Tasktop’s blog entry on Flow Distribution.
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.
For more details, visit Tasktop’s blog entry on Flow Velocity.
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.
For more details, visit Tasktop’s blog entry on Flow 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.
For more details, visit Tasktop’s blog entry on Flow Efficiency.
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.
References:
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.
For more details, visit Tasktop’s blog entry on Flow Load.
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.
To better understand how Value Stream Mapping and Value Stream Management are complementary, check out this white paper.
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.
What is the relationship between the 4 types of work mentioned in Gene Kim’s Phoenix Project (Business projects, Internal projects, Changes and Unplanned Work) and the 4 work item types in the Flow Framework (features, defects, risks and debts)?
Gene’s 4 types of work still apply, and are useful to describe how the work originates. The Flow Items are used to describe the kind of work that flows through the corresponding value streams. For example, if your SSO solution was constantly causing outages, you could be handling a lot of unplanned “defect” flow items. That might lead to noticing that there is a bunch of technical debt that needs to be done to remove dependencies on an old SSO tool, which turns into planned work as Debts and Features that are implemented. In other words, any of the 4 types of work can trigger any of the 4 Flow Items.
What about Program and Project Managers? What role do they play in the shift from Project to Product?
Project Managers have always needed better visibility into IT. Because much of IT work has been invisible, Project Managers have had to rely on practitioners to notify them of status changes, risks and issues. Making work visible is exactly what the flow framework provides.
To transition from scope based outcomes to value based outcomes, it makes sense that the PMO transitions to effectively help optimize those outcomes at a program level. Project Managers can be part of this positive transformation as they bring business relationships and understanding of business level goals to the table.
Important skills that transfer over from Program and Project Managers to a product-centric model include risk management and vendor management. Because the Flow Framework emphasizes business outcomes, those skills can bring visibility to the big picture and can be applied in a product model focused on driving value.
Customers of products are interested with new functionality but also concerned that things work the way they expect (defects) and that their privacy is not compromised (risks). The skills that Project and Program managers have (in “delighting customers” or being customer “obsessed”) are necessary ingredients to an organization moving into a product model which considers all these dimensions of customer satisfaction.
What is the link between the Flow Framework and Flow Academy’s Enterprise Flow?
The primary link between the Flow Framework and Flow Academy’s Enterprise Flow is the emphasis on the optimization of the flow of business value across the whole Value Stream.
When teams continuously improve one part of a value stream (what we call local optimization), it may seem like the right thing to do, but it doesn’t help the company overall if the bottleneck resides elsewhere. For example, Hiring more developers to create more features seems like a good way to improve customer satisfaction — until it’s discovered that developers sit idle while waiting on wireframes. If this is the case, it would benefit the company (and their customers) more by focusing on the bottleneck in the design phase.
The Flow Framework and Flow Academy’s Enterprise Flow (defined formally below) both practice the discipline of visualizing and studying the whole system to optimize business outcomes.
Flow Framework: A framework for managing software delivery that is focused on measuring and optimizing the flow of business value through product oriented software value streams that are correlated to business results.
Flow Academy’s Enterprise Flow is a framework for discovering, capturing, managing and delivering value. It is a customer-centered framework for enterprise transformation, work design and priorities that make extensive use of visual work and are often just-in-time.
How does the Flow Framework and SAFe support each other?
SAFe is a framework for scaling Agile and connecting it to the business. The Flow Framework, meanwhile, provides a business- and customer-centric view of what flows across the entire software delivery process. That includes the Agile parts provided by SAFe, the parts covered by other frameworks or practices (like ITIL), and the parts of the value stream (usually further upstream) where disciplined practices may not be in place at all.
By design, the Flow Framework is complementary to SAFe. And while the former doesn’t depend on the latter, most enterprises will see greater success with the Flow Framework if a scaling framework is in place. Whatever your approach, where the Flow Framework shines is in giving you a simple, high-level view of the effect of your Agile and DevOps transformations on business results. Read more here.
How do Flow Metrics support measuring BVSSH (Better Value Sooner Safer Happier) as defined by Jon Smart?
The ultimate goal for product teams is to provide better value to their customers sooner, keeping their personal information safer thus making them (and the product team) happier as described by Jon Smart (https://itrevolution.com/book/sooner-safer-happier/) . Flow Metrics can be used to support measuring how a product team is faring with respect to this goal.
Features and debts are units of value creation in the form of features or investing in the improvement of delivering future value in the form of debts. Defects and risks are units of value protection providing customers with higher quality (i.e. better) products that also keep their private information safe. Ensuring regulatory items are addressed assures safety from the company’s perspective.
The better the flow, the more effective (i.e. the sooner) R&D spend will be at producing business value. The four Flow Metrics are how we can measure that flow. Flow Time provides a customer and business centric measure of time to market and Flow Velocity does the same for throughput. Flow Efficiency measures how effectively investment turns into value and Flow Load is an early warning indicator of overloaded value streams declining due to too much work-in-progress (WIP). Flow Distribution measures that a balance in generating and protecting value is being accomplished as well as investing in improving flow.
Measuring the business results for the product track that the improvement in flow drives improvement of value delivered to the customer which improves customer happiness. Measuring the happiness of the product team is both a leading and lagging indicator for team productivity in that happy teams are more productive and productive teams are happier.
What is a good way to identify how many value streams you have in your software production?
Define value streams by what a customer is “pulling,” i.e., following the Unicorn Project’s 5th idea of Customer Focus. For the product value stream, you need a well-defined customer, internal or external to the organization and a product that encapsulates the value that they are pulling via feature requests. The value stream is then defined by all of the teams that need to support that. We generally see up to 10 agile/feature teams to support, i.e., value streams are a “team of teams-level” construct, not a team-level construct. Avoid equating value streams to agile/feature teams, as that is too granular. Note that you can cascade value streams into product lines or domains as we saw BMW present at the 2019 DOES London keynote. For some conceptual background, check out the DOES London 2020 “Team of Teams” keynote by David Silverman, as well as the “Team Topologies” work by Manuel Pais (co-author Team Topologies) and Matthew Skelton (co-author of Team Topologies).