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:
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.
[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.