The next pattern, Mitosis, is a scaling pattern. We often see Scrum Teams with a desire to scale, with the primary reason to increase output. However, market consumption must rise to match any production increase; otherwise, the excess productivity is just waste. In any case, the best way to grow a team’s output is by removing impediments and by improving the process.
Scaling legitimately occurs under just one circumstance: when the product grows organically to the point where the demand for new features outstrips even a high-performing Scrum Team’s capacity to deliver in a timely fashion. A “high-performingˮ team is one that has been a Stable Team for some time (see Stable Teams), maintains a consistent velocity, and continually delivers on business outcomes. If such a team, using Kaizen Pulse, has diminishing returns on its self-improvement efforts relative to the market’s required rate of delivery of business value, then it may be an option to add Development Teams.
Scaling is not about transforming an existing micromanaged organization to an Agile one (that is a quite different question; see Involve the Managers). When someone asks, ‟We have over 500 developers: how do we scale to Scrum?” is an example of someone asking the wrong question. How do they know they need 500 developers? Nor is “scalingˮ a proper response to a product that is late in delivery. Brook’s Law ([1], Chapter 2)—that adding people to a late project makes it later—still applies at team level. Scaling is about the piecemeal growth of the Development Teams in response to the growth of the product itself. Scrum has always scaled in that sense. Jeff Sutherland started the first multi-team Scrum at IDX in 1994. Exactly how Scrum scales is in large part situational, but the following patterns are common. Most of them fall within the scope of the Product Organization.
Reacting with the old muscle memory of waterfall, management’s knee-jerk reaction to a need for greater productivity is to add new people to existing teams, or to add new teams. In the big majority of cases this is a misstep. Scrum has its roots in the Toyota Production System (TPS), and one of its architects wrote a whole book based on the contrast between its approach and “large-scale productionˮ ([2]). The best approach is to:
Coach the Product Owner to focus the Scrum Team on the most important work;
Help the ScrumMaster to remove impediments; and,
Grow the Development Team’s ability to deliver quality-assured product.
In a minority of cases, the prescribed approach may be insufficient. But it is still necessary to first improve the Scrum Team to its maximum. Large organizations grow piecemeal from small organizations that work. That’s what this sequence is about. One may need to scale across geographically remote markets to meet diverse market needs (extensive localization or dependence on local laws, customs, or usage patterns). One may need to scale simply because of the intellectual mass of a single product. Examples include systems such as those that track and identify military threats and guide missiles to intercept them, or telecommunications products that must provide all telecommunication needs—local phone, toll calls, data, video, emergency services, billing, CRM, mobile, voice messaging, text messaging, Centrex, and business services—to a single market.
The following patterns focus on scaling a development effort. The underlying message is that it is best to scale Scrum using Scrum itself. The alignment of multiple teams behind a single product Vision requires that they work from a single Product Backlog managed by a Product Owner supported by an appropriately-sized Product Owner Team. Other patterns (like Definition of Done) are about the same as for single teams, with the change being only in unified scope of application (i.e., all teams share a common Definition of Done). Above all, the Development Teams’ self-organization and autonomy are preconditions for success. We present the patterns in a typical sequence of application that you may want to consider following if you plan to grow your organization.
§ 7 Scrum Team.
The starting point is always the single Scrum Team. Most organizations are tempted to “scaleˮ as a shortcut to fixing the team. In the absence of a high-performing team you will only be scaling your dysfunctions and adding complexity to your organization.
§ 12 Product Owner Team.
A Product Owner Team works under the leadership of a single Chief Product Owner to help with Product Backlog management across Value Areas.
§ 19 Mitosis.
If the product grows beyond the capacity of a single, high-performing Scrum Team to deliver, the team may hire additional developers. With too many people in the Development Team, the team splits into two smaller Development Teams. Organize the teams so that they remain Cross-Functional Teams and work across all parts of the product. The teams must keep delivering end-user functionality from a single Product Backlog. Organize development so that the Cross-Functional Teams can keep delivering end user functionality, following Conway’s Law.
§ 42 Scrum of Scrums.
With multiple teams working from the same Product Backlog, it is crucial to keep them all aligned with the product Vision. The self-organizing Development Teams collaborate to deliver common Sprint Goals, and coordinate with each other to resolve emergent issues and dependencies.
§ 45 MetaScrum.
Regularly coordinate among multiple products within an enterprise, and entertain management input through a forum that includes the Product Owners and executive management, which works on aligning the expectations of management stakeholders
§ 55 Organizational Sprint Pulse.
All the teams work in the same Sprint cadence and schedule to maintain a consistent view on progress. All teams together deliver an integrated single Product Increment at the end of each Sprint that is a Done contribution to furthering the Vision (in the sense of Definition of Done).
§ 97 Value Areas.
The product domains become too broad for all teams to understand, yet it is not possible to divide the product into separate sub-products in the market. The teams specialize according to areas of customer value, each one continuing to be cross-functional across its value area. This is a temporary organization, put in place until teams again grow to be cross-functional teams.
§ 98 Value Stream Fork.
Successful Value Streams may grow in scope. One problem with success is that the result can outstrip the original Vision. If so, split the Value Stream into multiple streams, each with its own Product Backlog, bringing focus and a refined Vision to each one.
[1] Frederick P. Brooks, Jr. “The Mythical Man-Month.ˮ In The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975, Chapter 2.
[2] Taichi Ohno. Toyota production system: Beyond large-scale production. Cambridge, MA: Productivity Press, 1988.