Value Stream Management: What is Flow Framework?-EN

Value Stream Management by Gabriel Cassarini y co-author Alonso Álvarez

In the previous article, we analyzed the problem of Nokia’s digital transformation. We commented that local, team-level optimizations and metrics were not aligned with the rest of the strategies and the entire value delivery chain. The focus was on measuring the execution of activities rather than taking a step back and measuring the impact of the transformation on the business results. Our primary goal in this article is to analyze the Flow Framework proposal to interconnect software development activities and measure their impact on business areas. We need to have traceability, manage the flow of the teams’ work and make better decisions based on data and results—a systemic and empirical approach.

It does sound a bit abstract. Let’s take it one step at a time.

What is a Value Stream?

The concept of value stream comes from industrial manufacturing processes and refers to the entire work stream, from the beginning to the end, from the moment a request arrives until the result is in the end-users hands. In this case, we refer to the whole sequence of activities, people and tools involved in software production. According to SAFe and Flow Framework, large-scale software production requires a 1-to-1 relationship between the dedication of the development teams and the value streams. In other words, each team should participate in a single value stream. Nothing more than focus and commitment. Applying this strategy to team construction increases efficiency, quality of work-and also improves engagement, increases knowledge sharing and a healthy team.

When we talk about value streams, it is crucial to include all stakeholders and actors. If we exclude, for example, support teams or sales areas, the result is not a value stream but segments of a flow. In that sense, agile and DevOps teams are segments. Segments are essential, but our goal now is to take a systemic, end-to-end view of the entire value stream and see how we can measure how the value delivery is going.

A taxonomy for each item

The first step to measuring is to identify the items that travel through the value stream. These units of work, which in the Flow Framework are called Flow Items, somehow represent the value delivered to customers and users. Agile teams use a backlog to manage work and set priorities. Flow Framework proposes the following taxonomy to classify backlog items:

• Feature: is a functional requirement with business value (user story, epic). Features represent user needs and are usually collected by Product Owners, stakeholders and business areas.
• Defect: is the correction of a defect (bug, errors, issues). Defects are usually reported by the quality team, users or the technical team itself.
• Debt: refers to the payment of the software’s technical debt. For example: to undertake improvements in the architecture to facilitate maintenance, automate tasks, and adopt new tools. These needs are usually detected by the technical teams – architects and developers.
• Risk: these are non-functional requirements such as security, compliance with standards and regulations (GDPR), and data privacy. In many cases, these requirements act as constraints on the design of the technical solution.

Having visibility and some degree of abstraction over the flow of items through the organization’s processes and tools would allow us to identify how many designers, developers, Product Owners, managers, testers and other profiles were involved in creating, deploying and supporting a particular feature.

Balancing the distribution

Teams must work on a balanced distribution of different types of items. The distribution can be varied over time to maximize business value-the primary responsibility of Product Owners. If too many issues arrive, some features will have to be de-prioritized from the backlog. If the pressure to deliver new functionality while fixing bugs does not stabilize, the technical debt will interfere with moving development forward after several quarters. Likewise, if risks are not explicitly prioritized in the backlog, they will never be implemented.

This technical information must be communicated to the business areas. The following image shows what happens when the team invests all its effort in developing new features and neglects quality and defect correction. Eventually, the debt becomes so large that it is impossible to continue developing new features, and the team is forced to stop completely to pay the debt. If we do not reduce this debt regularly, the software becomes prohibitively expensive and difficult to maintain and upgrade.

In many organizations, the business areas do not see this problem and continue to push teams to implement new features at the cost of increasing technical debt. In large technology companies, there tends to be more awareness of this problem because managers generally tend to have experience in software development. We need tools for leaders and less technical profiles to see this problem. Product Owners must optimize value delivery in the short term and consider the impact of not prioritizing backlog items. What would have happened if Nokia’s management had been able to visualize the effects of technical debt? 

In the following article, we will analyze the metrics proposed by Flow Framework to measure the work flowing through a software development value stream.

Part 3: Flow Framework Metrics