Change Management Week

Everyday this week!

Value Stream Management: What is Flow Framework?

Gabriel Casarini

Gabriel Casarini

Value Stream Management: What is Flow Framework?
Share
Share on email
Share on facebook
Share on twitter
Share on linkedin
Share on pinterest

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.

'Value Stream Management' illustration by Andy Baraja

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.

'Value Stream Management' illustration by Andy Baraja

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.

Join our #AlwaysLearning Community

About the Author

Gabriel Casarini

Gabriel Casarini

Gabriel Casarini, Netmind Lead Expert, SAFe Program Consultant and Software Architect, has a passion for developing and leading teams that build things. He is dedicated to streamlining teams and organizations, imparting experience, motivating, and teaching what agility is and how to make development teams highly productive. His professional experience is grounded in the belief that continuous improvement and adaptation are the only ways to truly optimize development processes, increase quality, and deliver greater value to the customer. Gabriel is a fervent advocate and practitioner of agile frameworks, TDD, and Lean Startup. He also brings extensive technical experience with the JEE platform and integration of open-source components, tools, and frameworks. Gabriel's unique combination of passion and experience contribute to his ability as an agile coach, mentor, consultant, and Scrum Master to help teams adopt a comprehensive vision and agile management approach that break through the challenge at hand. Connect with Gabriel on LinkedIn and check out his personal blog where he shares his vision on software engineering topics!

Related Insights

Onsite Training Request

Please provide the information below to help us to customize your solution. 

Contact Us

Netmind US
3372 Peachtree Rd NE, Ste 115
Atlanta, GA 30326
T. +1 (678) 366.1363

Office Hours:
Monday – Friday, 8:30-5:00EST

General Inquiries:
[email protected]

Sales Inquiries:
[email protected]

Request Information