Large-Scale Scrum: Change Implications

by Craig Larman

May 2014

In 2003, when I published Agile & Iterative Development [1], many “knew” that agile development was for small groups. However, I became interested in – and got increasing requests – to apply Scrum to very large, multisite, and offshore product development. So, since 2005 I have worked with clients to scale up – often for “embedded” and investment banking systems. Today, the two Large-Scale Scrum (LeSS) frameworks described in our books have been introduced to big groups worldwide in disparate domains, including telecom-infrastructure-equipment providers such as Ericsson [2], investment-banking clients such as Bank of America-Merrill Lynch and JPMorgan, plus many more.

Background
In 2003, when I published Agile & Iterative Development [1], many “knew” that agile development was for small groups. However, I became interested in – and got increasing requests – to apply Scrum to very large, multisite, and offshore product development. So, since 2005 I have worked with clients to scale up – often for “embedded” and investment banking systems. Today, the two Large-Scale Scrum (LeSS) frameworks described in our books have been introduced to big groups worldwide in disparate domains, including telecom-infrastructure-equipment providers such as Ericsson [2], investment-banking clients such as Bank of America-Merrill Lynch and JPMorgan, plus many more.
To quantify “large”, we’ve seen our LeSS framework-2 applied in groups of up to 1500 people, involving 7 developments sites spanning the globe. Our median experience is perhaps around 800 people on one product at 5 sites, with about 15 million lines of source code, usually C++, C, and Java.
Based on these experiences we published two volumes on scaling agile development and the Large-Scale Scrum frameworks summarized below: (volume 1) Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum [3], that explains the leadership and organizational design changes, and (volume 2) Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum [4], that explains concrete suggestions for scaling, including in product management, architecture, planning, multisite, offshore, and contracting. And we are next publishing a shorter summary book called simply Large-Scale Scrum. This article summarizes some of the change implications expanded in those books.
Large-Scale Scrum is Scrum: Change Implications
Scaling Scrum starts with understanding and being able to adopt standard real one-team Scrum. Large-Scale Scrum requires examining the purpose of single-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard “Scrum rules.”
If the entire R&D group was only seven people, the implications of changing to adopt true one-team Scrum are not dramatic, since many elements will “organically” be in place – as in a startup. But when a traditional R&D group of 500 people moves to Scrum, there are major change implications, and these need full understanding and support by senior leadership and hands-on producers. These include:
• Standard Scrum: A small (5-9 people) cross-functional Team of multi-learning team members that do everything end-to-end to develop the product (a real feature team [5]), and no specialized sub-groups within the Team, with the only title of “team member” or “developer” [6]. Change/scaling implications:
• No separate analysis group, testing group, architecture group, user experience group, platform group, etc. And no “tester” or “architect” within the team. That implies the dissolution of existing single-function groups and the management supervising roles, and the elimination of traditional career paths and job titles.
• Standard Scrum: The business-person “owner of the product” (such as, lead product manager) responsible for ROI and cost, and who can independently decide and change the content and release date becomes the Scrum Product Owner. The “owner of the product” steers development directly based on “inspect and adapt” and so is ultimately responsible for the product release, since they have the steering wheel. Change/scaling implications:
• Traditionally, the “owner of the product” negotiated a scope-and-date milestone-based “internal contract” with R&D managers, who were thereafter “responsible for the release.” Since the “owner of the product” (Product Owner) now steers directly, there is no shifting of responsibility to R&D to develop the release, and no “internal contract.”
• Since the “owner of the product” steers development directly and is responsible for the release, there is no separate R&D or IT program/project manager responsible for the release; that role is eliminated.
• Standard Scrum: Each 2-4 week Sprint, from the first, the product increment must be “Done” and potentially shippable – a Potentially Releasable Increment. Each Sprint the system must be implemented, integrated, fully tested, documented, and capable to deploy. Change/scaling implications:
• The concept of a “big release” and the constraint “it’s not ready until the end” dissolves. This implies eliminating “big release” management systems, practices, roles, and policies that are predicated on a long phase of messy partially-done development before the system is ready.
• Scrum is not for “the programming phase” after analysis and before testing. There is no prior “analysis phase” or “architecture phase” and no following “integration/testing phase.” Sequential life-cycle development is eliminated, and with it, the groups that were attached to each phase (the analysis group, ...).
• Standard Scrum: The Team is self-organizing (self-managing) and is empowered to independently decide how to achieve their goal in the Sprint. Change/scaling implications:
• There is no team lead or project manager that directs or tracks team members, which implies the elimination of related team-lead and project-manager roles.
• No organization-wide “standard” process that everyone must follow.
This is simply standard one-team Scrum, but its adoption especially challenges traditional R&D assumptions and organizational design at scale. Therefore, most groups do not adopt real Scrum, but instead “customize” it (into “fake Scrum” or “Scrum, but...”) rather than change themselves.
Conclusions
Real agile development with Scrum implies a deep change to become an agile organization; it is not a practice, it is an organizational design framework.
Start a large-scale agile Scrum adoption by ensuring leadership understands the organizational implications, and they have been proven adoptable in the small scale.
References:
[1] Larman, Craig. Agile & Iterative Development: A Manager’s Guide. Addison-Wesley, 2003.
[2] Ericsson R&D Center Finland, “How we learn to stop worrying and live with the uncertainties”.
[3] Larman, Craig & Vodde, Bas. Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum. Addison-Wesley, 2008.
[4] Larman, Craig & Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.
[5] Larman, Craig & Vodde, Bas. Feature Team Primer.
[6] Vodde, Bas. “Specialization and Generalization in Teams”.