Flow Framework: Implement End-to-End Value Stream Management

Original

Flow Framework is first proposed by Dr. Mik Kersten in the book Project to Product. Since then, it has been adopted by IT leaders around the world to bridge the gap between technicians and business stakeholders. The Flow Framework provides methods and glossaries to systematically mitigate and eliminate bottlenecks in software delivery that impact business results.

I. Why is a new framework needed?

There are many approaches and frameworks for business transformation, modernization and process re-engineering, while some focus on enterprise software delivery, such as Scaled Agile Framework (SAFe®). The latest progress in DevOps practices has addressed software construction and release bottlenecks. Other frameworks approach the enterprise transformation from a business re-engineering perspective, such as Geoffrey Moore's Zone Management. While DevOps and Agile principles significantly impact the way technicians work, they are too technology-centred to be widely adopted by business stakeholders. A new framework that can span business and technical languages and support the transition from project to product is needed to bridge this gap. That is the Flow Framework, whose role is to ensure that business-level and transformation initiatives are connected with technological frameworks. The framework is expected to extend the three ways of DevOps-process, feedback and continuous learning - across the business. That's the goal of the Flow Framework.

II. Flow Framework

The Flow Framework® provides a blueprint for enabling value stream management, connecting IT and business, and transforming traditional businesses into high-performance technology companies. The whole framework is divided into four layers.

• The bottom layer is Tool Network, linking ideation, creation, release and operation, represented as an integration model, which the connectivity index can measure.
• The second layer is Artifact Network, linking various activities to build an activity model, which the traceability index can measure.
• The third layer is Value Stream Network, linking values to build a product model, which the alignment index can measure.
• The top layer is Value Stream Metrics, with eight metrics ranging from flow metrics (flow velocity, flow efficiency, flow time, flow load) to business results (value, cost, quality, happiness). These metrics are based on the flow distribution, which will involve distributions of features, defects, risks and debts.

Image Source: Flow Framework

III. Flow Distribution

Flow Distribution is the proportion of flow items (features, defects, debts, risks) in a specific value stream that can be adjusted according to the need for maximized business value. Set by the staff who best understand the current state of the value stream and support what is needed for the value stream and the staff in the process, the flow distribution provides the development team with an opportunity to have important conversations with business people/product managers about how to weigh the business impact. A high-speed functional flow is great for new product releases, but it usually comes at the expense of other items, such as bugs and debts, weakening the product's value. Flow distribution can help us to define business priorities.

We can set the metric for the whole organization to achieve business goals. Microsoft's "Trusted Computing" initiative, for example, focuses companies on risks and security improvements. If an enterprise is under threat from other companies that are more agile, it may want to move from the old platform to the cloud and optimize software delivery to quickly bring new features to customers.

Another case: A product used by 22,000 clinical practitioners in a large US healthcare enterprise is experiencing a very high call volume for Helpdesk, affecting developers' ability to develop features. Most of the problems are not software defects but misunderstandings about new features, although these could be resolved through dialogue and communication. However, this cost consumes a lot of bandwidth and reduces the ability of the value stream to develop new features. Therefore, some suspect that weekly releases of new features and changes to workflows are too fast for clinical practitioners, and the flow distribution metrics confirm this hunch.

By analyzing the flow distribution, they could see that the workload is highly skewed towards defects, leaving little for developing new features.

Based on the above assumption, the pace of weekly feature releases is too fast for the user community to absorb, so they decided to postpone the release time to every four weeks, coinciding with the monthly newsletter.

The communication and training department produces the newsletter and lists all the changes that will take place in the upcoming releases. Maintenance releases are still issued weekly. This quick and easy change results in a 95% reduction in trouble tickets and a tripling of Feature Velocity.

IV. Flow Efficiency

A major part of flow metrics is to track all work involved in planning, building and delivering business products, such as tracking how much value is delivered, how long the work takes and how much Work-In-Progress (WIP), and tracking what work (programming, testing, design and all creative work) is actively being done to determine if its waste and waiting for states hinders value delivery. Flow efficiency is the percentage of the time flow items (features, defects, debts, risks) are actively working on as a percentage of the total time spent in the value stream. If the flow efficiency is low, then the WIP is often in a waiting state for some reason.

Here we can see the domino effect: more items waiting means more WIP and longer queues in the value stream. As the queue grows, waste will increase, and even the delay will be further increased due to the overuse of context switching. The flow efficiency metric can easily see the excessive waiting times and the reduction and elimination of bottlenecks.

It is important to note that this metric is based on flow time (the time it takes to complete work from the time it enters the value stream) rather than cycle time (the time it takes to complete a single step in the manufacturing process). Thus, the flow efficiency can capture the upstream and downstream waiting times, monitoring the entire value stream from end to end.

The value stream of an enterprise usually includes many work states and transitions. So many changes can make it difficult to determine where work is waiting. Therefore, it is important to be able to abstract this information. The flow framework can enforce four key states: new, active, waiting and completed. For example, the large US healthcare company mentioned above can use flow efficiency as a metric of its improved processes. Despite the strong flow velocity, the team's happiness is very low, and people complain about too many context switches.

For more information, please visit: https://flowframework.org/