Improving Enterprise Performance with Value Threads

By Alex Yakyma

Value Stream is one of the key concepts of Lean|Agile development at scale. A value stream is a set of steps, starting from the definition of the idea of a new functionality all the way through to the implementation and deployment to satisfy user and business goals. Another aspect of a value stream is people – the teams that contribute to the end user value. Thus, a value stream is most often the set of steps (and a number of teams) required to develop or maintain a software solution. More often than not, value streams consist of multiple collaborating agile teams.

Let’s start by summing up the key reasons why we care at all about value streams and value stream analysis. As we know from experience, a value stream perspective allows an organization to effectively focus on:

1.       Improving the process as a whole, thereby genuinely improving it.

2.       Continuously improving the average cycle time.

3.       Enhancing quality by building it into every process step.

4.       Actively creating, sharing and evolving relevant knowledge.

These are all meaningful goals that allow an organization to considerably enhance its operational performance. Surprisingly enough, however, value streams alone don’t let you improve these at scale and here’s why.

Let’s consider an agile program that works on a specific value stream, consisting of seven agile teams. The result of their work is an end-to-end solution – a large software system for which the teams advance the functionality and nonfunctional requirements, as required by the business. What can we say about such a value stream? Just as for any value stream at scale – not much. It consists of five process steps that repeat indefinitely over feature sets:

Figure 1. Value stream perspective

Figure 1 doesn’t say very much, primarily because we have tried to outline process commonalities for all seven teams and those are pretty generic and therefore, not overly useful. The process is much more complex inside and requires much more subtle treatment. In fact, such a rough perspective (as seen in figure 1) can be largely harmful to the program for the following reasons:

·         Applying Work-In-Process (WIP) limits on the entire program in a “wholesale” manner may unbalance the flow instead of stabilizing it

·         Some teams may have their unique, context-dependent steps in the process which substantially impact their performance but are not visible as a part of the value stream.

·         The specific ways in which the teams impact one another in the program usually has a dramatic impact on the overall program performance and requires special treatment.

In order to explore the internal structure of a value stream at scale, we need to take a microscopic view. What seems to be a flat surface to the naked eye may turn out to be an entire new world with its own ridges, peaks, plateaus and trenches. We will start our journey by defining the ground rules. We will be zooming in for a closer look at a value stream, but only insofar as we don’t lose the features (chunks of an end-to-end user value) from sight.

The reality of most programs suggests that the teams collaboratively create user value and that the patterns of such collaboration are context dependent (See figure 2).  

Figure 2. A value stream consisting of a number of value threads

So, features 1 and 2 require three teams to work together, feature 3 involves four teams, and feature 4 requires two teams’ input. The teams that are connected with a same color link form up a Value Thread – a subset of a program teams that are able to deliver a specific feature or a feature set. Value threads can be as small as one team (in case of feature teams, for example) or can be as big as the entire program (often, when it consists of component teams).

Most interactions occur within the value threads. Thus, in order to be able to improve the process at scale, we redirect our focus from an overly abstract value stream to significantly more detailed value threads. We would like to see value being created in a fast, synchronous manner within each value thread, as Figure 3 suggests:

Figure 3. Synchronous work on a feature within a value thread

Now it is obvious that the following Lean|Agile techniques make a lot of sense primarily within a value thread:

• Applying WIP limits.
• Backlog grooming, planning, tracking progress and demonstrating the results.
• Measuring the feature cycle time and cumulative flow.
• Creating and sharing knowledge.
• Advancing in test automation, and collective code ownership
• Collectively retrospecting and improving the process.

It is unarguably better to move towards feature oriented agile teams, where a team actually is a full value thread. In reality, however, this is far from always possible or may require a huge amount of time and effort. Uncontrollably bloated technology stacks, narrow specialization, geographical distribution, and organizational impediments – these can all present serious hurdles when moving towards feature teams. However, once value threads are made visible within an organization, it may considerably increase managerial support and willingness to make changes as they start to see the real source of existing inefficiencies.

Start by asking yourself several questions. What are the smaller constructs (value threads) within my program that are responsible for end-to-end value delivery? Are the teams aware of their peer teams, with whom they have to actively collaborate? How many sprints does it take to deliver an end-to-end chunk of functionality within such a thread? Do teams collaboratively plan and track progress within the thread? Now that you know what your target object is – you can help your organization improve. It will be a tough journey, but the prize is also worth it.

In future posts, we will explore different important aspects of the value threads and offer further practical advice in terms of applications.