Value Stream Fork

Sometimes you need to break an egg to make an omelet.

... your product has become a success in the market, and there are frequent requests for changes and extensions. The product starts to take on a new face that is increasingly distant from the initial Vision or finds itself needing to serve two or more markets with divergent needs, economies, or release cycles. Market data suggest that consumer identities have a strong link to product identity; diluting product uniqueness or identity may reduce product attractiveness. The broadening scope of work dilutes the focus of a single Scrum Team so it is unlikely to meet the demands of all markets in a timely fashion. The question arises as to whether this is feature creep or a business opportunity, and in light of the potential for increased value the Scrum organization ponders how best to meet the demand.

✥       ✥       ✥ 

There is some correlation between feature richness and profitability, but development costs can grow disproportionately large relative to casually adopted increases in product scope. Stories abound about the percentage of developed features that are rarely or never used. Systems nonetheless evolve to keep pace with changing end user demands, and agile development helps to lubricate that process. We often think of these changes in terms of tweaking existing functionality, but it’s probably more common that products grow in capabilities. Such change are sometimes large enough that a product can start to take on a new identity. Habit formation is a strong force in product use, and when the product changes enough to confound end user expectations and habits it can disrupt sales (as happened when New Coke replaced Coke, or when Windows Vista® broke much compatibility with the Windows NT® and Windows XP® traditions). However, the pressure to distinguish one’s self against the competition is strong in a market where novelty reigns — as is true in most agile businesses today, for better or worse. So products grow.

If you start by defining a product too broadly, the product lacks focus and direction, and users may have difficulty identifying with it. The same can happen over time if a product suffers scope creep. If, on the other hand, you start with a narrow product definition, you can broaden the product as the Product Owner assesses the market’s ability to absorb new features and the enterprise’s ability to manage the growth. It’s noteworthy that great products grow from small products that work. A product should ever be mindful to rise to market demand and to remain competitive against new features from the competition, but it should also be mindful to retaining its identity. There is an essential tension between market breadth and product identity. Research establishes that consistency in product identity is one of the greatest indicators of profitability. [1] The same research suggests that “being agile” by following fashion hampers long-term profitability. However, clinging to a single identity to the extent that the enterprise ignores the market can lead to results as extreme as the death of the product or even the enterprise — as happened to one of the subject corporations in [1]. There is broad research that shows that consumer choices are driven by a need to differentiate themselves from others based on product properties, [2] but that the need for such differentiation varies according to the degree that individual identities are entangled in the product identity. [3]

The product may evolve beyond the bounds of the initial Vision. The Scrum Team may consider process improvements that would increase its velocity enough that the Product Owner can deliver to each market as needed. However, the nature of these improvements may differ for different markets. The team loses focus trying to serve both the original Vision and alternative, emergent Visions as well. This lack of focus lowers the team’s velocity.

You could grow the Development Team to increase capacity, yet we know Small Teams are most effective. Scrum builds on team autonomy, and the addition of every new team on a complex product reduces the autonomy of existing teams. If the product is complex it cannot easily be partitioned into independent parts, which suggests that individual teams are unlikely to sustain autonomy over their development. Research shows that if we compare the output of a five-person teams with that of 20-person teams, that they are about the same: there is a schedule gain of about one week over eight or nine months. [4] What distinguishes the larger teams are their higher defect rate and a 400% lower rate of efficiency. [4], [5]

Even if these Small Teams can work independently, Conway’s Law says that the product taxonomy should also reflect small, independent chunks, because these products are ”most important concerns for the creation of value” for the enterprise as a whole. Or we could increase capacity by adding a Development Team to the existing product, but that detracts from each team’s autonomy and adds coordination cost. A common rule of thumb is that, all other things being equal, going from one team to two adds about 40% overhead.

Growth often takes place by a broadening of the product into multiple Value Streams, sometimes with the appearance that each stream delivers a distinct product. One can indeed feed multiple Value Streams with a single development effort from a single Scrum Team if that team has the capacity to deliver to all streams in a timely fashion; see Value Areas. For example, much of the differentiation between the iPhone® and iPad® is in the skin and packaging, while sharing the bulk of development. If all Value Streams are driven from a single Product Backlog the Product Owner must interleave product release sequencing from several Value Streams, which makes it more difficult to develop a release vision for any single Value Stream. Because a single product construction strategy may not optimally fit each of multiple release strategies for different markets, it is difficult for a single backlog to simultaneously reflect all these perspectives.

A large product can realize economies of scope. However, uniformly marketing all of a large product’s features to a single market is likely to confuse the consumer. That suggests that ultra-feature-rich products still need multiple Value Streams and multiple market outlets. On the other hand, differentiating a single product for each of several Value Streams makes the product more complex. While the Product Owner and Development Team for a mega-product can act autonomously (see Autonomous Team) the marketing and sales efforts cannot. Simple, conceptually integral products grow in complexity as parts are added to support some new product option, while being able to still call it one product. Just about anyone who has tried to support multiple markets that share a complex, evolving component can attest to the challenges that come along with this approach. In the worst case (or often, over time, in the end) it drives the product to a “one-size fits all” mentality to retain development economies of scale.

There may even be legal forces for splitting a product into multiple products, such as which caused Microsoft to have to unbundle Internet Explorer from Windows®. We become limited in our ability to tailor existing products to add market differentiation.

The usual reasons to keep a single product are motivated by production concerns such as maintaining a small “parts catalog,” interoperability, and code sharing. However, experience shows that the cost of sharing non-commodity code can outweigh the benefit because of the need to coordinate the corresponding development efforts; having a small “parts catalog” overly constrains the ability of production to support innovation. Additional motivations might include political forces such as broadening the span of control of a powerful manager, or giving in to a tradition of command-and-control management, or a fear that individual products will locally optimize instead of developing a portfolio that delivers the Greatest Value. These are often anxieties that come with agile transitions.


Grow a product’s functionality — along with its supporting development organization — to the point where at least two of the product’s Value Streams have distinct delivery cadences, rates of feature change, market ergonomics, or business contexts that suggest that there should be more than one product identity. Split the product into multiple products corresponding to the dominant Value Streams. Each product will have its own Product Backlog and Product Owner.

✥       ✥       ✥ 

No product needs to coordinate how it develops any component with any other product. The remaining external dependencies are mostly commodities.

Each product can now independently be evolved to serve its market and Value Stream. If there are common commodity components across the new products, those can be produced by yet a third organization (but only in the case that they are commodities — otherwise you have increased the number of handoffs). Non-commodity common parts can have an identity (e.g., be structured as a framework, particularly in software) but the responsibility for development of such shared parts can remain a shared, coordinated effort. The Product Owners should oversee the coordination of such efforts where possible.

In the meantime, this product organization supports market freedom and flexibility. The market is no longer required to take a given browser with a given operating system (as in the above example of Explorer and Windows), because each market Value Stream has its own product identity so users can purchase it separately. As a consequence, products are more likely to evolve along the lines of standard external interfaces rather than building on proprietary technology.

This raises the decision of major functionality growth to a business decision, dealt with within the business framework of Scrum (i.e., by explicitly identifying a new Product Owner) instead of being allowed to evolve into a form of “feature creep” at the market level.

So the iPhone becomes the iPhone and the iPad — almost identical products with largely shared development, but in different packaging. Coke becomes Coke Classic and New Coke. Each Product Owner now has greater autonomy to tailor a product to a particular market, rather than having to compromise, commoditize, or deal with complexity in terms of development coordination. Further and perhaps more important, each Product Owner has freedom to direct her or his Development Teams. Each Scrum Team has autonomy in ordering its PBIs for release of its product, without undue concern for weaving in releases for another Value Stream.

Common commoditized parts can still be shared across these products as a product line, much as many car models share the same chassis and engine. As an example, Skoda Octavias serve one market while Volkswagen Golfs serve another — but they share most of the same infrastructure.

The Apple product ecosystem is a good example of this kind of differentiation. Building on a common base that started with a music player, Apple differentiated it into a phone product while still retaining the music player (and though the phone probably contained much of the music player software, the hardware packaging was completely new), and later further differentiated into the iPad tablet, and finally further differentiated both the phones and the tablets. While all products shared many sales channels, the products represented rather independent Value Streams whose products were quite differently marketed.

Value Areas is an alternative pattern that can be used when the organization can realize economies of scope by coordinating all Value Streams with a single Product Backlog. It is a matter both of the coupling between “latent Value Streams” (and therefore, of the communication overhead between their teams) and of the ability or willingness of the producing organizations to cooperate. Value Stream Fork is based on the assumption that all Product Owners work together as a team, perhaps under the auspices of a forum such as the MetaScrum. For example, the enterprise may decide to run one of the products as a loss leader, and the corresponding Product Owner makes that a central consideration of the product value proposition. Value Areas balances the forces that arise when Product Owners are unable or unwilling to do this, but need to have their control consolidated under a Product Owner with a broader span of control. This limits individual Value Areas’ autonomy and may be well-suited to product lines that do not need agile decision-making at the “latent Value Stream” level. Value Stream Fork maximizes product autonomy. It raises the number of autonomous entities, but it reduces the overall amount of control in the system. [6] It is a cooperative work environment based on trust (see Community of Trust). It tends to produce more entities that interwork according to standards, which is a major lean foundation. So Value Stream Split suits Spotify, [7] which is built around autonomy and a flat management structure, and Value Areas suits hierarchical organizations such as one commonly finds in military and public sector contracting, where there is often a legacy of top-down product integration. [8]

Consider also Conway’s Law.

[1] Vorgelegt von Hyeshin Ahn. “Research on Product Identity by analyzing the examples of Mobile Phones.” Ph.D. Thesis at Universität Duisburg-Essen, 2007.

[2] Charles R. Snyder and Harold L. Fromkin. “Abnormality as a Positive Characteristic: The Development and Validation of a Scale Measuring Need for Uniqueness.” In Journal of Abnormal Psychology 86, October 1977, pp. 518-527.

[3] Jonah Berger and Chip Heath. “Where Consumers Diverge from Others: Identity-Signaling and Product Domains.” In Journal of Consumer Research 34. Oxford, UK: Oxford University Press, August 2007.

[4] —. “Haste Makes Waste: When You Over-Staff to Achieve Schedule.” Compression Quantitative Software Management, n.d. (before 2012), (accessed 12 April 2017).

[5] Carl Erickson. “Small Teams Are Dramatically More Efficient than Large Teams.”, 11 January 2012 (accessed 13 April 2017).

[6] Daniel Katz and Robert L. Kahn. The Social Psychology of Organizations. New York: John Wiley and Sons, 1978, p. 314.

[7] Henrik Kniberg. “Spotify Engineering Culture Part 1 (Agile Enterprise Transition with Scrum and Kanban).” (accessed 18 April 2017).

[8] Cesário Ramos and Sandra Roijakkers. “Thales Surface Radar Case Study.”,, 2015 (accessed 2 November 2017).

Picture from: