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. 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 changes 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, sales can get disrupted (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. The product’s creator should ever be mindful that the product meet market demand and remain competitive against new features from the competition. But, he or she should also be mindful that the product not lose any valuable identity it has gained through market exposure or use. 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 the source just cited. There is broad research showing that consumers make their choices out of 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. That need varies from product to product. [3] We don’t wrap our identity around products that we think of as commodities, such as eggs or paper towels. But our identity is in gear for high-tech products. For example, 76 percent of iPhone users cannot imagine owning any other kind of phone, and the rationalization is wrapped up in the owners’ identity: “The first driver behind why we buy a particular product is self-identityˮ ([4]).

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 (see Notes on 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, then the vendor cannot easily partition it 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 twenty-person teams, the outputs are about the same: there is a schedule gain of about one week over eight or nine months. What distinguishes the larger teams are their higher defect rates and a factor of four lower rate of efficiency. [5]^,[6]

Even when 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 percent 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 the bulk of development is shared. If a single Product Backlog drives all Value Streams, the Product Owner must interleave product release sequencing from several Value Streams, making 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 they incorporate new features while still retaining their identities as single products. 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 those that caused Microsoft 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 come from production concerns such as maintaining a small parts catalog, interoperability, and code sharing in software. 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.

Therefore: 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 development team (Scrum Team) needs to coordinate how it develops any component with any other product. The remaining external dependencies are mostly commodities.

The teams can now evolve each product independently to serve its market and Value Stream. If there are common commodity components across the new products, then yet a third organization can produce them (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., domains from software to automobile manufacturing have parameterized platforms) but the responsibility for developing such shared parts should 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 browser is no longer packaged with the 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 each 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, handled within the business framework of Scrum (i.e., by explicitly identifying a new Product Owner) instead of evolving into “feature creep” at the individual product 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 his or her Development Teams. Each Scrum Team has autonomy in ordering its Product Backlog Items for release of its product, without undue concern for weaving in releases for another Value Stream.

Multiple products can of course still share common commoditized parts, 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. Product line architectures and business organizations can emerge.

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). Apple later further differentiated the phone product 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 Apple marketed quite differently.

Value Areas is an alternative pattern that applies 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 reduces the overall amount of control in the system ([7], p. 314). 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 Fork suits Spotify, [8] which has largely autonomous teams 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. [9]

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-27.

[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] David Glance. ‟The Psychology behind Apple’s Fans. Blind loyalty or just wanting to belong?” The Conversation, https://theconversation.com/the-psychology-behind-apples-fans-blind-loyalty-or-just-wanting-to-belong-31671, 14 September 2014, (accessed 9 July 2019).

[5] —. “Haste Makes Waste: When You Over-Staff to Achieve Schedule.ˮ Compression Quantitative Software Management, n.d. (before 2012), http://www.qsm.com/risk_02.html (accessed 12 April 2017).

[6] Carl Erickson. ‟Small Teams Are Dramatically More Efficient than Large Teams.” https://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-large-teams/, 11 January 2012 (accessed 13 April 2017).

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

[8] Henrik Kniberg. “Spotify Engineering Culture Part 1 (Agile Enterprise Transition with Scrum and Kanban).ˮ YouTube.com, https://www.youtube.com/watch?v=4GK1NDTWbkY (accessed 28 January 2019).

[9] Cesário Ramos and Sandra Roijakkers. “Thales Surface Radar Case Study.ˮ Less.works, https://less.works/case-studies/thales-surface-radar.html, 2015 (accessed 2 November 2017).

Picture credits: Image Provided by PresenterMedia.com.