Scrum Scaling

Prior to scaling any project, an appropriate infrastructure must be put in place. For instance, if a project will employ multiple collocated teams , a mechanism for frequently synchronizing their work must be devised and implemented. Also, a more detailed product and technical architecture must be constructed so that the work can be cleanly divided among the teams. If these teams are to be geographically distributed, high-bandwidth technology for source code sharing, synchronized builds, and alternative communications such as instant messaging must be employed.

Everything that supports the scaling effort must be devised and implemented prior to the scaling of the project; all of this work is done in Sprints. But Scrum requires that every Sprint produce an increment of potentially shippable product functionality, and you might be asking how this requirement can be met if months are needed to devise and implement a scaling infrastructure. Indeed, even though less business functionality will be created during these initial Sprints to build infrastructure, it is still necessary to demonstrate some business functionality at the end of these Sprints. In fact, it is all the more important to do so because this allows the infrastructure to be tested with functionality development work as it evolves. Demonstrating business functionality also enables the production of the kind of results that the Product Owner and stakeholders value so highly from the very start and goes a long way toward keeping them engaged in the project.

The nonfunctional requirements to build the scaling infrastructure are given high priority in the Product Backlog because theymust be completed before scaling begins in earnest. Because business functionality must be demonstrated at the end of every Sprint, these nonfunctional requirements are mixed with top-priority business functionality, and sometimes even outrank that functionality. If a piece of business functionality is dependent on a nonfunctional requirement, the nonfunctional requirement must be prioritized in the Product Backlog so that it is developed prior to or in parallel with the business functionality. The more scaling is required, the more the top-priority Product Backlog will be heavily skewed toward nonfunctional requirements for scaling. In such instances, more effort will be expended on preparation and less on direct business value until the scaling infrastructure is in place.

The process of defining and prioritizing the nonfunctional requirements for scaling is called staging . Staging occurs prior to the start of the first Sprint and takes just one day. During this day, the nonfunctional scaling requirements for this particular project are determined and placed in the Product Backlog. For example, if you are scaling the project to use multiple teams, the following nonfunctional requirements should be added to the Product Backlog:

• Decompose business architecture to support clean-interface multi- team development.

• Decompose system architecture to support clean-interface multi- team development.

• If necessary, define and implement a development environment to support multi-team collocated or distributed environments.

After these nonfunctional requirements for scaling are placed in the Product Backlog, Sprints can begin. However, only one team can sprint until the scaling infrastructure is in place, as there of course will be no mechanism for coordinating the work of multiple teams in the meantime. See Figure 9-1 for a representation of the initial Product Backlog with all nonfunctional requirements appropriate for the type of staging envisioned . The Product Owner and Team get together at a Sprint planning meeting and collaborate to select a combination of functional and nonfunctional requirements. The Team then sprints as many times as required until the infrastructure for the staging is in place. At this point, the Sprint planning meetings for each of the multiple Sprint Teams can be held. Each new Team is seeded with a member of the original Team, who serves as the new Team ‚ s expert on the project ‚ s infrastructure and architecture.

Figure 9-1: Scalability Sprints

These practices are some of those that were required to scale a Y2K project that was undertaken in the late 1990s. During this period, almost every organization was trying to ensure that its software was Y2K-compliant and wouldn ‚ t cause problems upon the dawn of the twenty-first century. In the next section, I will describe how an organization used Scrum scaling techniques to orchestrate a large project aimed at upgrading its software for Y2K and then helping customers implement the new release.