Why look at this
The concept of the value stream is a critical aspect of Lean and systems-thinking. The value stream is the set of actions that take place from concept, to realization of value, that add value to a customer. The efficiency of a value stream, and the amount of feedback it provides during the workflow taking place in it has a huge factor on true productivity.
We look at value streams because they provide us with a way of looking at the flow of work instead of focusing on individual productivity. Pre-Lean thinking looks at each step in the process with the presumption that if we improve each step we can improve the overall process. Lean-thinking tells us we should focus on the workflow across the organization and reduce the time between the steps. Looking at value streams provide us with a way to do this.
This shift in what we look at represents a shift from resource efficiency to flow efficiency. Having people be efficient by working 100% of the time is flawed thinking. There are three challenges with this. First, it focuses us on people doing the work instead of quick value delivery (see Inherent Challenges at Scale for more). But it also almost always results in people being on multiple projects and therefore being forced to do considerable task-switching. These two combine to create delays in the value stream which not only slows down delivery of value but injects waste into the system.
Good value streams also allow for quick feedback of whether what is being developed truly has the potential for value.
Symptoms that the value streams are ineffective
Inefficient value streams typically have 3 characteristics:
- The people involved in them are working on several other value streams when it would be better if they were in just one value stream
- there are a significant number of handbacks (that is, work being handed back to an earlier stage in the value stream)
- work waits a significant amount of time between steps
- people aren’t collaborating
- Workflows are not visible
- What’s being worked on is not visible
- Teams are focusing on what they are accountable for and not assisting with other projects\
- There is no common cadence or synchronization across teams that need to work together
- integration errors
What causes inefficient value streams
- a project has people allocated to it on a part-time basis. This causes work to be distributed across more people than needed which increases dependencies, communication and delays between steps
- people multi-tasking making the work wait more often than it would otherwise (not to mention lowering people’s general efficiency)
- poor work flows, in particular, not being clear on what done is prior to starting work
- lack of collaboration in projects that require multiple teams to get accomplished will incur great delays in workflow than necessary. These delays will create additional work. It is also likely that the most important things won’t be worked on.
- lack of alignment on what’s most important to be worked on
- HR policies that reward individuals or teams based on their own performance
- people working on too many thing
What we want to achieve
A project to product mentality would enable us to have one project having people being allocated to it full time while the people are allocated only to this project. This is ideal. Note this is what Scrum attempts to achieve with its cross-functional teams working on one project guided by a product owner.
Although value streams run from concept to realization of value, when a part of the value stream is reasonably contained with one input and one output, a focus on flow within it can be useful. For example, the value stream of a Scrum team. We should be focusing on flow from Sprint backlog to done, not just what individual teams members are doing (see Manage Work-in-Process (WIP) by Focusing on Finishing for more).
People working together to minimize the cost of delay of what’s being created.
At a high level, efficient value streams can be created by allocating people full time to a project. This both limits the number of people on the project as well as limits the number of projects people are working on. A rule of thumb (candidly, guessing at this number) is that anytime someone is allocated after their first project allocation, allocate 20% of their time to accommodate the additional task switching and delays that will result. This “penalty” does not need to be incurred if an additional project has a short cycle time where the work they have to do for it fits into the context of the first, thereby not causing task switching.
Another step is to make dependencies visible so people can see what is required of them and when they may get help from others. Having an agreed upon sequence of work to be done when a team gets multiple requests from multiple sources is also useful.
For more on factors that make a value stream less efficient see The Value Stream Impedance Scorecard (VSIS)
Other simplicity factors that are directly related to this one
- The value density of the items being worked on
- Batch size of work
- Effectiveness/efficiency of the value streams
- Visibility of work and workflow
- How workload relates to capacity
- A minimal number of interruptions from outside the value stream
- The rate at which we get feedback
- Quality of the product
- The value creation structure of the organization