Appendix B:
Scaled Scrum
The Scrum Guide
describes a framework within which a team of 5 to 11 people can organize itself to deliver sophisticated software products quickly and efficiently. Each team needs a Scrum Master, a Product Owner, and three to nine developers to be fully staffed. Experience has shown that such a group of people can be remarkably productive, but the small size of the team does impose limitations on size of the products that can be developed.
A small team of people can accomplish quite a bit. One need only consider the case of the famous
Obamacare online application
called
HealthCare.gov
. It was originally developed by a Canadian firm that employed hundreds of developers. After its disastrous debut, the entire application was rewritten from the ground up. After the rewrite, the web site worked quite well and caused no more controversy. It is true that the rewrite took almost a year to accomplish, but the remarkable thing is the size of the team that did it. After hundreds of developers failed to deliver a working product, the web site was reimplemented successfully by a team of just ten people.
Theoretically speaking, a properly organized team of three to nine people should be able to create
any
product. The team members need the support of a good Scrum Master and the guidance of a good Product Owner, but a self-organizing team can figure out how to deliver any kind of functionality needed.
One may try to counter this assertion by saying that three to nine people cannot possibly have all the skills necessary to develop a modern multiplatform system. The answer to this argument is that the self-organizing team need not have expertise in all the relevant technologies
at all times.
The team can adjust its membership as needed, adding expertise in certain technologies and dropping others as required. A single self-organizing team can create any kind of product, no matter the size, simply by taking steps to adjust itself so that it remains fully cross-functional and able to deliver whatever finished work it plans to complete at the end of each sprint.
Why Have More Than One Team Work on a Product?
If a single
self-organizing team
can create any kind of a product, then why would more than one team ever be needed? The answer is straightforward. A single team can create any product
given enough time.
The
only
reason to employ more than one team to develop a product is to develop it
faster
than can be done with one team alone. A single team can develop a very complex product such as Microsoft’s Office suite, but it may take them years to do so. Products such as this one are usually given to a number of teams to work on together. The idea is that if one team can create a product over many months, a number of teams working together can reduce substantially the time required to deliver a finished product.
The idea of having many teams work together to create a product is generally called
scaled scrum
.
In theory, scaling up Scrum can shorten the overall development time by allowing different parts of a product to be created in parallel. It is generally recognized that the improvement in throughput cannot increase in a linear fashion. For example, if one team can deliver after six months, two teams cannot necessarily deliver after only three months. Still, the notion that “many hands make for short work” is driving a tendency in the software industry to put dozens (or even hundreds) of teams to work developing a single product.
Scaling the Scrum Framework poses a
fundamental challenge
. Almost all of Scrum’s success depends on having self-organizing teams that are cross-functional. In other words, a Scrum team must manage itself and must be capable of creating the finished product with no outside help. If more than one team is involved, how are they managed? If more than one team is involved, that means (by definition) that neither one can create the finished product without outside help. The Scrum principles of self-organization and cross-functionality are both challenged when more than one team is involved.
There are quite a number of scaled Scrum frameworks that have been developed over the years to try to deal with the problem of organizing multiple teams to create a single product. Some of the more notable ones are DADS (Disciplined Agile Development System), LeSS (Large-Scale Scrum), SAFe (Scaled Agile Framework), Scrum@Scale, and The Nexus. All of these frameworks have their proponents and their detractors, and it is not my intention or purpose to wade into the spirited controversy about which approach is “best.” These pages illustrate the importance of dealing with the issues of self-organization and cross-functionality in the context of multiple teams, and describe how one of these frameworks approaches the problems.
Cross-functionality vs. Self-organization
In many ways, the need for cross-functionality and the need for self-organization are in conflict in any Scrum team. Having enough people with enough different skills means a bigger team is a better team. At the same time, the bigger the team, the harder it is for the team members to manage themselves. If the team is too small, it probably doesn’t have the ability to create the finished product. If the team is too large, it probably cannot agree on where to go to lunch, let alone make joint decisions about creating the product. In many ways, the guideline of “three to nine developers” in
The Scrum Guide
represents a compromise between these two conflicting needs.
With multiple teams (which really means many more than three to nine developers), the ability for them to self-organize becomes very problematic. The developers
must
manage themselves for the Scrum Framework to be effective. They must choose what they will do and how they will do it, or they will feel no accountability for the result.
Also, if the work of developing the product is divided among more than one team, then the issue of
interteam dependency
is introduced. If team A is working on a function that relies on the work of team B, then team A is dependent on team B to reach its own target. Team A cannot complete its work with “no help from the outside.” Team A and team B must coordinate their efforts for both of them to succeed.
The
Nexus
Framework
In 2015, Ken Schwaber and some of his associates published
The Nexus Guide
, a companion to
The Scrum Guide
meant to provide an “exoskeleton” for extending Scrum principles to three to nine Scrum teams.
The Nexus Guide
(available for download at
http://www.Scrum.org
) describes a structure that, if used properly, preserves self-organization within the developers and provides a mechanism for minimizing and managing interteam dependencies.
A
Nexus
is a set of three to nine Scrum teams all working to produce a single product. Because only one product is involved, there is only one Product Owner and one Product Backlog. The overall cadence of the sprint cycle is maintained, with each sprint starting with a planning event and ending with a sprint review and a sprint retrospective. There are still daily scrums. The major difference involves the way in which sprints are planned and how sprint retrospectives are handled.
Before sprint
planning
can take place, the Product Backlog must go through a special product backlog refining process, the purpose of which is to identify potential interteam dependencies in the work to be done. This refinement is done by a special Nexus integration team of developers, working with the Product Owner. Their job is to identify dependent PBIs so they can be grouped together. The idea is that if the items are grouped together, they can be allocated to the same teams and thus avoid as much as possible the need for cross-team coordination.
After the backlog has been refined, the Nexus sprint planning event can take place. Just like the traditional Scrum sprint planning event, the Nexus version is a two-part meeting. The first part consists of a negotiation between the developers and the Product Owner about
what
is to be done. The second part consists of the developers making a plan for
how
to do it.
For all the developers to feel accountable for delivering the result, they must all take part in the negotiation about what is to be done. Therefore, the first part of the Nexus Sprint Planning Meeting is a single meeting that involves all the developers in the Nexus. They negotiate with the
Product Owner
about the items in the Product Backlog to be done. They agree on a Nexus sprint goal and select a number of PBIs that become the Nexus sprint scope. At that point, the first part of the Nexus sprint planning event comes to a close.
The second part of the Nexus Sprint Planning Meeting should result in sprint backlogs for each of the teams that reflect plans to accomplish all the PBIs selected during part 1 of the meeting. To do this, the entire group of developers then
divides itself into teams
and selects appropriate PBIs on which to work. They select items in a manner that minimizes cross-team dependencies. After the teams are formed and the PBIs are selected, the teams then create their
“traditional
” sprint backlog.
After the sprint backlogs for each team are created, team members start their development work. They hold their daily scrums and manage themselves to deliver what they have forecast. The Nexus
integration team
keeps track of interteam dependencies and makes sure they are visible to all concerned. The teams write and integrate their code to produce a single “done” version of the product by the end of the sprint. That version is then reviewed in a single sprint review. The Nexus adapts the Sprint Retrospective event to take into account that there may be lessons learned at both the Nexus level and the individual Scrum team level, but other than that, the Nexus preserves as much of the basic Scrum Framework as possible.
As we can see, the Nexus
exoskeleton
adapts self-organization for multiple teams by providing different venues and contexts for decisions about
what
is to be done and
how
it will be done. The negotiations with the Product Owner about sprint scope are done with the developers operating as a single group. Thus, they all have a say in what is to be done and they are all accountable for delivering it.
When it comes to deciding
how
to deliver the agreed-on scope, the developers divide into normal teams of three to nine people and tackle the problems at the team level. Small groups of talented people can solve technical problems much better than large groups. This situation is identical to that of a traditional Scrum Development Team.
In traditional Scrum, the developers negotiate with the Product Owner about the scope they will accept and then make a plan (the Sprint Backlog) to deliver that scope. In the Nexus exoskeleton, the developers also negotiate with the Product Owner and make Sprint Backlogs. The only difference is that, in the Nexus, the developers have the added responsibility of dividing into appropriate teams before they create the Sprint Backlogs.
Summary
Scaling Scrum without crippling it involves adapting the imperatives of cross-functionality and self-organization to a multiteam context while managing the interteam dependencies that are an inevitable result. The Nexus exoskeleton does this by keeping all the developers as one self-organizing body for some purposes, then having them divide into smaller self-organizing bodies for other purposes.
Other frameworks provide other approaches to deal with these issues. I have made no attempt to compare them and have no opinion regarding which approach is the most effective. It is valid, though, to state that the effectiveness of an approach depends on the effectiveness of its way of reconciling the needs of self-organization and cross-functionality in a large-scale product development effort. Self-organization and cross-functionality are the keys to the success of single-team Scrum. Any form of multiteam Scrum must preserve them as much as possible or lose the benefits of the Scrum Framework altogether.
