The Value Stream concept
In the Lean community, Value Stream Mapping is widely used to create an enterprise-wide strategic view, essential for optimizing the entire flow. Value Streams are not equivalent to Processes broken down into steps to improve local working procedures. Process level mapping enables people who do the work to make tactical improvements. The Value Stream level provides leadership with a macro perspective and a strategic view, enabling lasting improvements.
Still, Value Streams for product development are mostly modeled on a detailed level with little impact when optimizing the entire flow. The intent to create a macro-level visualization that would help top-level managers understand their organization’s performance then falls short. When limited to optimizing the system development process only, managers lose interest, and there is a risk of the process map becoming a rigid control system of how people should work daily.
This article explores Lean sources and outlines examples of enterprise-wide Development Value Streams.
A Value Stream in a Functional Hierarchy
An organization chart is often visualized with silos that each has a functional responsibility. In such a hierarchy, the actual Value Stream can take a long and winding road through various departments until something valuable has been created.
This is where the Value Streams come into play. Value streams are a fundamental concept in Lean thinking, and they help us understand the entire flow needed to transform a request into something of value.
As we will see later in this article, Value Streams are not always one-path linear sequences but a network of interrelated processes. Development Value Streams are challenging to model, given that they mainly involve intangible items and must address future uncertainty differently from operational ones.
In the Lean and Agile communities, Development Value Streams are expected to be visualized in the same style and intent as production flows. In the Scaled Agile Framework (SAFe), Development Value Streams are the fundamental starting point for organizing development around value.
It’s, however, hard to find examples of the entire development flow from start to finish rather than just the development process. This is problematic because transformations to Lean and Agile are likely to fail if not all entities of an organization support the flow of value. We must explore the macro-level targeted in the Value Stream concept to achieve successful large-scale transformations.
Granularity level of Value Streams
Many distinguished authors have written about Lean and Toyota. Two of these are Mike Rother and Karen Martin, who have contributed much to the knowledge of Value Streams. Both Karen Martin and Mike Rother are clear about the intention of Value Streams and what granularity is needed.
Mike Rother says:
“Taking a Value Stream perspective means working on the big picture, not just individual processes, and improving the whole, not just optimizing the parts.”
In other words, Karen Martin says the same:
“Value Stream maps offer a holistic view of how work flows through entire systems and differ from process maps in several significant ways.”
Karen Martin continuous:
“Many organizations are misusing Value Stream mapping .. using Value Stream mapping to map at a process level misses the entire point of Value Stream mapping: viewing work systems from macro-level perspectives to create organization-wide alignment.”
I have the same experience as in Karen Martins’s statement. I have found it challenging to get the attention of the managers who own the Value Stream level and are the only ones with the authority to reorganize the flow. They regard Value Stream workshops as finding all the nitty gritty details of one process. They do not see that Value Streams are about understanding the strategic view.
In the book Value Stream Mapping, Karen Martin has visualized the granularity levels.
In this picture, the breakdown of Value Streams becomes apparent, and it is evident that Value Stream mapping and process mapping serve different purposes.
It becomes confusing when the description of Value Streams in SAFe depicts them as a series of “steps” instead of “processes.” Even if SAFe clarifies that “Each step represents a significant process in the Value Stream performed by a distinct function,” it would have been more informative to use the exact wording as the original.
Although SAFe has the same intent as Karen Martin, many organizations and facilitators bypass the process level and jump directly into details before working on the whole picture, where the fundamental challenges are found. The following example illustrates the steps involved in one process, commonly mistaken for a breakdown of a Value Stream.
This example is unlikely to interest higher-level managers. Even if multiple teams work on a complex “Smoke Test,” it doesn’t align with the conventional understanding of organization-wide alignment.
Besides being on a detailed level, all examples I can find are modeled as a linear sequence of activities. This is usually called waterfall development, which is far from how Agile teams operate. When practicing agile, the order of work steps may change frequently depending on the need and opportunity to improve. If managers are involved in defining work steps to be performed in a specific order, self-organizing will fly out the window.
The entire Development Value Stream
The Development Value Stream can be extensive in a large organization. To gain a common understanding of how work is organized, we need to start at the highest level and identify the involved processes. Everything from the enterprise portfolio, which is responsible for strategic planning and major initiatives, to the release in production should be included.
Even if encapsulated in more significant initiatives, the development flow of a new feature may start in the strategic planning process; it is then refined, approved, and prioritized by several units before the feature reaches the development process. After development, the feature may not work as intended in the first hand-over to operations but needs to iterate through the change management process.
This example does not intend to show the exact linear flow but rather to give an overview of the processes that work together in a large organization. In many cases, there are more processes with more complex relationships.
When viewing the entire flow from start to finish, it is easy to understand that a multitude of business units with unique processes are involved in developing a solution. The unit working according to the system development process usually takes responsibility in the middle of a Value Stream.
I have also noticed that small organizations (< 100 employees) are not free from working in silos where each department has its process. Marketing/sales, business development, and customer service are the usual entities that should be recognized as parts of an end-to-end Development Value Stream.
Interaction between Process Types
In a Development Value Stream, processes interface in many ways. Input and output are less tangible than in an Operational Value Stream, and exceptions and workarounds are more common.
To give an example of how challenging it is to combine processes of different types, we can examine the standard collision between project management, change management, and system development processes. These processes are complicated to combine since they work inconsistently in their core.
Project Management
A traditional project management process is based on phases that all projects should undergo. These phases, also known as process groups or the project lifecycle, all interface with the system development process. For example, in the planning phase, a project should acknowledge development standards, and engineers may be required to make estimates.
A project management process does not last for the lifetime of a solution but supports a temporary project team with the intent of delivering a specific solution, after which it will be terminated. Individuals may simultaneously belong to multiple project teams.
Change Management
Like the project process, change management requires close interaction with the development process. For example, development standards must be acknowledged when conducting impact analyses, and engineers may be required to make estimates.
A change management process supports the operation of a solution and controls the lifecycle of any changes. It may also support projects in managing complex changes or changes in an operating environment. The aim is to enable beneficial changes to be made with minimum service disruption.
System Development
A development process following older frameworks like the Systems Development Life Cycle (SDLC) is easily aligned with a project process since it also has distinct work phases.
A development process based on Lean-Agile thinking, like the Scrum framework, is an apparent mismatch with a project process. Agile frameworks do not have phases. Instead, the solution evolves in small increments through a range of iterations. Planning is continuously embedded in the process and is not done as a separate activity long before development.
A Lean-Agile development process enables one or more teams to take complete responsibility for the entire lifecycle of a solution, including stakeholder collaboration, operation, development, and any other necessary tasks. It is recommended that long-lived teams prioritize continuous improvement.
A flawed Process Interaction
To illustrate how these incompatible processes interact, we can take a snapshot of how projects and systems change interface with one or more development teams.
This figure shows how:
- During the planning and execution phases, projects A, B, and C require one or Agile teams to perform analysis and development.
- Ongoing change management requires Agile teams to analyze the impact in system Y and implement changes in system X.
- The teams work Agile, prioritizing everything in their backlog.
The interfaces are mismatched because Agile teams expect to get business objectives and user needs as input, while projects and change management focus on activities and resource requests. It’s important to note that Agile teams might also be involved in incident management and are expected to have time for technical advancements to increase productivity.
The interaction between the processes may be further complicated by frameworks such as PMI, Scrum, SAFe, DevOps, ITIL, and others, each promoting its unique thinking and terminology. When separate entities implement these frameworks to support different processes, it becomes challenging to establish a flow-based system.
The different natures of the three processes suggest that aligning processes on a higher level is more important than optimizing each process individually.
Development Value Streams as networks
A Development Value Stream is much more complex than Value Streams in a production environment, where a sequence of physical objects is easily observed. In “The Principles of Product Development Flow,” Donald Reinertsen even says that viewing product development as a sequential flow is a “silly model.”
He explains, “Existing sequential processes force many low value-added activities to occur every project.” Instead of a “linear sequence of steps,” Donald Reinertsen suggests that product development should “be viewed as a network.”
The visualization of small sequential steps in Development Value Streams is not only low-level but also does not reflect how information flows through a system. Organizations must take a holistic view of their Value Streams to optimize their product development and recognize them as networks. This will help them understand the entire flow and identify areas for improvement.
The Items that Flow through a Value Stream
The whole purpose of working with Value Streams is to optimize the flow of valuable items throughout the system. However, organizations generally have no clear definition of a flow item. As we saw earlier, Agile teams may take responsibility for delivering backlog items. However, the possibility of understanding and monitoring flow is inconceivable when the other processes of a Value Stream concentrate on activities and resources.
“Project to Product” by Mik Kersten is an excellent source for understanding what items flow through a Development Value Stream. In line with Donald Reinertsen, this book defines a product development flow as not linear but “a flow across a complex Value Stream network.”
Organizations must clearly define the items flowing through the system to understand how a Value Stream operates. This allows them to monitor and improve the Value Streams effectively. The items that flow through development should be as well-defined as the physical components in production.
Following the flow
Let’s discuss if it would be possible to follow the flow in an organization that is bound to traditional project control and is new to Lean thinking. Assuming:
- The top management is engaged and prepared to improve product development methodically.
- The process owners are involved and open to improvement.
- They have been able to visualize the network of processes in a Development Value Stream.
Even with a vague definition of flow items, it would be possible to follow the path of investment decisions—where and by whom flow items are prioritized. In Figure 4 above, it is likely easier to spot flow items at the beginning of the Value Stream. Processes in the early stages are tightly coupled to business objectives and define both outputs and outcomes.
However, flow items tend to disappear as you move downstream in discussions about funding, costs, solutions, resources, and other factors. Processes in the middle stage are primarily intended to ensure decisions are made by the correct authority and according to established policies. At the middle management level, there is a risk of greater emphasis on safeguarding and developing careers rather than on innovative business decisions.
Flow items reappear at the end of the Value Streams, sometimes bundled in large releases and sometimes as small, high-priority features with high market value. Even if the processes at the end are split into development and operations, they focus on end-user features.
Identifying flow items at the beginning and end of the Value Stream would open for exciting metrics, such as lead time and the number of finalized initiatives.
Strategic Improvement
Understanding the boundaries of a Value Stream and creating a baseline of flow metrics provides a foundation for improvement. After identifying processes with different structures and mindsets, the way forward would be to reduce the number of processes while continuously measuring the effects of the changes.
To exercise your thoughts about Development Value Streams, could you consider the consequences if the budget, resources, and project management processes were removed?
- What responsibilities would need to be altered?
- What control mechanism would need to be replaced?
- Which new risks are likely to appear?
- Can we introduce new metrics?
The exact improvements needed are naturally unique for each organization. The abovementioned case emphasizes the importance of utilizing Value Streams at the enterprise level. This is clearly far from optimizing a “Smoke Test,” as indicated in Figure 3, and it requires top management to engage in methodical organizational development.
“Support from top management is not sufficient. It is not enough that top management commit themselves for life to quality and productivity. They must know what they are committed to—that is, what they must do. These obligations cannot be delegated. Support is not enough: action is required.”
Conclusion
Development Value Streams are more complex than operational ones and are often modeled as a lower-level development process. The purpose of Value Stream mapping is not to make process improvements but to attain a strategic view of the entire development approach. Therefore, it is essential to keep a high-level perspective and involve the management with the authority to make changes above the process level.
Many organizations work in a hybrid model where activity- and flow-based processes are supposed to collaborate. However, processes with contrasting mindsets and interfaces cannot work well together. Instead of a linear sequence, Development Value Streams are a network of interoperating processes with varying connections. Consequently, people who develop organizations must understand the different characteristics of processes and avoid mixing processes that do not work well together.
Creating an understanding of the flow of a system requires knowledge and authority. Top management rarely takes active responsibility for aligning processes throughout an organization. They give middle management the responsibility to choose the working method and accompanying tools, leading to local optimization. Also, consultants and tool vendors reinforce local optimization because it is easier to sell to a silo than to a whole organization. Working on the entire scope will have a much higher impact.
Value Streams offer a powerful way to gain an overview of the entire development flow, identify areas of improvement, and drive strategic changes.
References
Value Stream Mapping by Karen Martin and Mike Osterling
Learning to See by Mike Rother and John Shook
The Principles of Product Development Flow by Donald Reinertsen
Project to Product by Mik Kersten
The Essential Deming by W. Edwards Deming and Joyce Orsini
Development Value Streams by Scaled Agile
Value Stream Management by Scaled Agile
Portfolio Flow by Scaled Agile
Why Value Stream Mapping is Essential to Product and Process Development by Lean Enterprise Institute
Product Development Value Stream Mapping by Hugh McManus
Creating a Development Value Stream map by AWS Prescriptive Guidance
Systems Development Life Cycle by Wikipedia
Process Groups: A Practice Guide by PMI
Project Management from the Middle by Gary Somma at PMI
About the content
The intention of the Articles published on this website is to provide exciting knowledge about organizational development in any business. BDD hopes this knowledge will help take your organization to the next level. The information is based on our experience supporting many transformations and cutting-edge sources published in books, articles, and frameworks.
