The idea of the Flow Framework started with my attempt to visualize manufacturing like production flow for software delivery. The core premise of the Flow Framework is that we need to measure the end-to-end flow of business value.
The Flow Framework focuses entirely on the end-to-end value stream flow and its correlation to business results. The measurement is done via the ground truth of software delivery that is observed by the flow of artifacts through the Value Stream Network layer. Agile and DevOps metrics and telemetry lie a layer down below the Flow Framework. For example, if an Agile team is constantly struggling with meeting its release goals, the SAFe or Scrum frameworks can provide metrics and guidelines for better prioritization and planning. In contrast, the Flow Framework is focused on the end-to-end metrics used to identify where those bottlenecks might lie in the first place—if they are upstream or downstream of development, for instance.
In addition, the Flow Framework avoids measures of activity in favor of tracking flow metrics and correlating them to results. There are no metrics of “how Agile” or “how DevOps” an organization is, just a focus on how much business value flows through each value stream and what results it produces. If responsiveness to the market is a key need, the Flow Framework can highlight flow and feedback cycles that are too slow for a particular value, implying that more Agile practices may be needed.
The role of the Flow Framework is to help you determine the outcomes of your investments in Agile and DevOps practices, and to supply you with the metrics needed to improve those practices. The goal is to provide you with a means of scaling flow, feedback, and continual learning to work not just for dev and ops, but for the end-to-end business process of software delivery.
Go with the value stream flow
At the top level, the Flow Framework provides two things. First, the Value Stream Metrics allow you to track each value stream within the organization so that you have a way of correlating production metrics to business outcomes. Second, the Value Stream Network layer provides the infrastructure needed to measure the results delivered by each product.
At the highest level, the Flow Framework is a mechanism for aligning all delivery activities in your organization around your software products, tracking the business results of those activities in order to create a results-driven feedback loop.
To do that, we must switch to first principles and define the customer, what they are pulling, and how this pull can be implemented as value stream flow. Once one or more value streams are defined, we need to focus on making value(s) flow smoothly across those value streams. But before we do that, we must define the units that flow along a software value stream.
The Flow Framework is designed to work at the largest of organizational scales and to support stringent regulatory requirements where needed. This means that even the most traditional, complex, or safety-critical organizations can apply the concepts to drive software innovation at the right pace for their business. In order to do this, we first need to understand the four main flow items that make up the framework.
Four flow factors
Every time that I have asked a senior or executive-level IT leader where their bottleneck is, I have received either a blank stare or a vague answer. But when set in the right context, just the thought process of exploring this question makes a serious issue apparent. The vast majority of enterprise IT organizations do not have a well-defined productivity measure for what flows in their software production process.
Measure productivity
It is impossible for the business to have a shared understanding of a bottleneck without having a shared understanding of productivity. Contrast that to the automotive industry, where the number of cars produced is a very clear productivity measure of an automotive value stream. Worse yet, it’s not just those organizations that are scrambling to align around metrics that matter; it’s the software industry as a whole.
There is no clear consensus from academia or from industry thought leaders on what constitutes software development productivity. Organizations know it when they see it—perhaps through products that drive market adoption and revenue faster than others. But correlating development activities to those results has been more of an opaque art than a disciplined activity. To define productivity in a value stream, we must first define what flows.
To do that, we need to go back to the first principles of Lean thinking summarized earlier in this chapter. Lean thinking starts not with the product but with the value the customer pulls. If we think back to the early days of software, with companies stamping out installer disks packaged in shrink-wrapped boxes, we could try to draw an analogy to car production and define the widgets produced as those boxes. But that analogy was weak then and is rendered irrelevant in this time of continuous delivery and the cloud. If customers are not pulling releases, what value does the customer pull?
To pull value, the customer must be able to see that value and be willing to exchange some economic unit for it. For an internal product, this could be adoption (e.g., having different business units adopt a common authentication system). For an external product, the unit can be revenue; or in the case of a product with indirect or ad-based monetization, such as a social media tool, it might be time engaged with the product. For a government or not-for-profit organization, it can be the adoption rate of a newly launched digital offering.
Understand the value stream
Using any of these scenarios, consider the last time you derived new value from a product or went back to using a product that you had previously not used. What triggered that exchange of value in terms of spending your time or your money? Chances are that it was a new feature that met your usage needs and perhaps delighted you in some way. Or it was the fix for a defect that was preventing you from using a product that you had otherwise valued. And here lies the key to defining what flows in a software value stream: if what we are pulling is new features and defect fixes, those are the flow items of a software value stream.
If these are the flow items, that means we could characterize work across all the people and teams within a value stream as applying to one of these items—and we can. Given full visibility into every process and tool in the organization, you could identify exactly how many designers, developers, managers, testers, and help-desk professionals were involved with creating, deploying, and supporting a particular feature. The same goes for a defect. But is this the only work that is being done within the value streams?
Include all work in the value stream
The "Mining the Ground Truth of Enterprise Toolchains" analysis of 308 enterprise IT tool networks identified two other kinds of work that are invisible to the user but are pulled through the value stream by a different kind of stakeholder. First, there is work on risks. This includes the various kinds of security, regulation, and compliance that must be defined by business analysts, scheduled onto development backlogs, implemented, tested, deployed, and maintained. In other words, this is work that competes for priority over features and defects, and as such, is one of the primary flow items. This type of work is not pulled by the customer, as regulatory or compliance-risk work is usually not visible to the customer until it is too late (e.g., a security incident that leads to a number of security defects being fixed and security features being added). It is instead pulled internally by the organization; for example, by the Chief Risk Officer and their team.
Reduce technical debt
The final and fourth kind of work is technical debt reduction, which describes the need to perform work on the software and infra- structure codebase that, if not done, will result in the reduced ability to modify or maintain that code in the future. For example, a focus on feature delivery can result in a large accumulation of technical debt. If work is not done to reduce that technical debt, then it could impede future ability to deliver features; for example, by making the software architecture too tangled to innovate on.
While the concepts of risk and technical debt are not new in the Flow Framework, the focus on the measurement of each flow item results in a very different set of conclusions as to how they should be managed. In using the Flow Framework, the only technical debt work that should be prioritized is work that increases future flows through the value stream. Tech debt should never be done for the sake of software architecture alone, like using it to improve the separation of architectural layers. This means that the flow of each of the flow items should shape the software architecture and not the other way around, which is counter to the way many enterprise architectures have been evolving.
This post is an excerpt from Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, by Dr. Mik Kersten.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
