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.
