Using the Assembly Line Approach for Value Stream Identification

This article introduces the Assembly Line Model as a practical tool for identifying and visualizing value streams. It helps map how value is created – from component integration to final delivery – by capturing key activities, hand-offs, and the people involved. The resulting model creates the clarity needed to support better decisions and is a critical precondition for exploring future options for organizing around value.

‍The Assembly Line Model

A high-level introduction and rationale for using the Assembly Line Model were already provided in the article „Visualization of Value Streams“. In this follow-up, we take a closer look at how the model is applied specifically to value stream identification.

Let’s begin by revisiting the high-level stages of product development. We distinguish four key stages:

• From Idea to Backlog – understanding what we want to build and translating it into actionable (backlog) items
• Backlog – managing and prioritizing the work to be done
• From Backlog to Delivery – actually building the product until it is ready for release
• From Delivery to Value Realization – ensuring the product delivers value through effective deployment and usage

While all of this can be modeled using the Assembly Line approach, we will begin by focusing on the “from backlog to delivery” segment – since this is where the model most clearly diverges from traditional methods.

Value Stream Identification involves more than just modeling – it is a small project in itself that requires project management and supporting activities. These aspects are outlined in the article “How to Start – Single Value Stream”. For orientation, the full process is illustrated in the diagram below, with the key elements covered in this article highlighted in red.

‍Modeling with the Assembly Line

Let’s begin by clarifying the desired outcome of the modeling effort before exploring how to achieve it.
The goal is to create a model of the current product development process, viewed from an assembly perspective (see image below).

The Assembly Line model shown in the image below is read from right to left. It begins with the final product we aim to deliver and marks the end of the value stream scope at the point of hand-off to the customer(s).

The blue boxes represent the individual development and assembly stages, starting with final integration and testing, and working backward through the decomposition of integrated components. Within each blue box, we document the necessary activities (blue circles) and define the acceptance criteria for passing the product or component to the next stage.

We also include yellow boxes to show the involved departments, teams, and individuals, and use grey boxes to indicate external suppliers or partners or other dependencies.

Importantly, this model also generates information that is synchronized with both the Issues & Findings list and the Value Stream Canvas, ensuring alignment across analysis and improvement efforts. In some cases it can also lead to adjustments in the VSI Charter.

To enhance visibility, it is often helpful to visualize and reference issues and findings directly within the model itself – making them easier to locate, understand, and address in context. You can do this by numbering the Issues and Findings on the model. We use the numbering here just to navigate you through the individual elements.

The Modeling Steps

We will now take a closer look at the individual elements of the Assembly Line model. While there is a natural order to how the model is typically built, this sequence can be adjusted based on context and need. It often takes several iterations to arrive at a meaningful and complete model, involving input from different experts across relevant domains.

The level of detail added to the model should align with the information needed for the next step: exploring future options for organizing around value. Capturing all involved people, teams, and roles is especially important, as this will enable us to answer key questions about how these individuals might be organized in future scenarios.

1 – Agree on the Final Product¹ and Specify it

Here we refer to section three of the Value Stream Canvas: 3. Value Delivered & form of Value Delivery. While this may sound trivial, experience shows it often isn’t— which is why we explicitly ask to write it down. From a product development perspective, the delivered outcome varies by context:

1. In software, it may be a binary, an installable package, a container image, a Java archive, etc.
2. In hardware, it’s typically a physical component or device.
3. In cyber-physical systems, it’s a combination of hardware and the embedded software running on it.

Clearly defining what the team delivers is essential to anchoring the value stream model and clarifying its scope, hand-off points, and responsibilities.² This step often raises the question of product variants, as many teams develop multiple versions, variants, or configurations of the same product. Before modeling begins, it’s important to decide which ones to include or exclude. In most cases, it’s best to start with a single, representative variant rather than attempting to model the full complexity of all variations at once. A deeper look at the strategic considerations behind variant management can be found in the article „Variant Management„.

2 – Hand-off to Customer(s)

“Your customer is the next person or process that depends on your output.”³ – This is a core principle in Lean, Agile, and DevOps thinking. While this „customer“ may not be the buyer or end-user of your „Final Product“, they are essential for maintaining flow in product development. Supporting that flow requires clarity about where our responsibility ends and where the handoff to the next station begins. This mindset also calls for a supportive, collaborative attitude toward the consumers of our work – one that prioritizes global optimization over local efficiency. Ensure this insight is reflected in Section 4 (Primary Customer[s]) of the Value Stream Canvas.

3 + 4 – Final Integration and Testing + Integrated Components

Once the product and its hand-off to the customer(s) have been defined, we can begin visualizing the value stream. The key question at this stage is:

What components are integrated to build the final product, and what must happen to make it ready for hand-off?

To begin, focus on identifying the components to be integrated—this is Step 4. Start by sketching the blue boxes to create a blueprint of the assembly stages.

Next, return to the rightmost blue box, where final integration and testing occur. In this box, document the specific activities required to prepare the product for hand-off. These may include tasks like:

• Consolidating and understanding the release notes of the components (new features, bug fixes, known issues, …)
• Installing and configuring integrated components
• Running various kinds of tests
• Performing quality and compliance checks

The green circle in this context represents the acceptance criteria for the hand-off. All the blue boxes represent the activities needed to reach this point, including their feedback cycles – for example, refining steps within each stage as issues are found during integration and testing.

After completing this step for the Final Integration and Testing box, continue by working leftward through the value stream. Decompose each identified component in the same way, until you’ve reached a level of detail that is sufficient for your specific purpose.

Whether each component also requires detailed activity descriptions (blue boxes) and corresponding acceptance criteria (green circle) depends on the depth needed at this stage. In many cases, this level of detail is refined later—during the optimization phase-once the initial structure of the value stream is in place.

5 – Adding involved People and Teams

At this point, it’s time to consider the people involved in creating the final product and its components. The level at which you associate people or teams with specific activities depends on the size and complexity of your value stream.

In smaller cases, it may be sufficient to draw a red circle around certain blue boxes to indicate responsibility. In more complex scenarios, you may need to tag individual blue circles (representing specific activities) or use a combination of both approaches.

The key objective is to ensure that all involved individuals, teams, or departments have been clearly identified and linked to the relevant parts of the value stream.

6 – Adding people outside your responsibility

In many cases, a value stream depends on shared services or functions that lie outside your direct responsibility – often with limited influence over how they operate. However, since value cannot be created without them, it’s important to represent these dependencies in the model. You can do this by using a different color or symbol to clearly distinguish them from elements within your control.

7 – External suppliers

External suppliers are somehow similar to people outside your responsibility. You can document them on the model but the blue boxes are not transparent and can turn to grey.⁴

Conclusions

The Assembly Line approach offers a structured yet flexible way to visualize and analyze how value is created and delivered within a product development organization. By modeling the flow of work from final integration back to component creation—and anchoring it in clearly defined outcomes, responsibilities, and hand-offs – we make the value stream visible and actionable.

This visibility enables better decisions, targeted improvements, and meaningful discussions about how to organize around value. While the modeling process often involves several iterations and input from a range of experts, the clarity it produces forms a solid foundation for the next step: creating and evaluating future organizational options. This is where we begin to explore how work and teams can be organized more effectively to align with the flow of value.

Notes & References

1. Within the Assembly Line, we refer to the final outcome of the value stream as the “Final Product”—even though, in a broader context, it may actually be a sub-product or component of a larger solution. Depending on the context, we may also refer to sub-products that are assembled into more comprehensive products or solutions. The terminology used depends on perspective. For example, if a company develops a charting library, that library is their product. However, for an application that uses the library, it is merely a component or sub-product. Ultimately, the “right” naming depends on the viewpoint of the stakeholder—it is, in many ways, in the eye of the beholder. ↩︎
2. In very large and complex environments, a single value stream can become so extensive that it must be divided into smaller, more manageable value streams. In these cases, the value stream under analysis typically delivers a sub-product—a component or capability that contributes to a larger system. The final product is then an aggregation of many such sub-products, each developed and delivered through its own dedicated value stream.
   If this applies to your situation, it’s often wise to narrow the scope initially and focus on one sub-product. This allows you to deliver meaningful results within a reasonable time frame—while laying the groundwork to expand to the broader system later. More about larger value streams can be found here: Working with Large Value Streams. ↩︎
3. This perspective is reflected in the work of Mary and Tom Poppendieck (Lean Software Development), Gene Kim’s The DevOps Handbook and The Phoenix Project, as well as Skelton and Pais’s Team Topologies – and is echoed across many other Lean, Agile, and DevOps sources. ↩︎
4. The degree of potential collaboration with people outside your area of responsibility—or with external vendors—is often limited. However, revisiting collaboration models and contracting approaches can increase transparency and may become a key opportunity for improvement. ↩︎