When Service1st started using Scrum, the organization consisted of individuals working on their assigned
in isolated workspaces. A friend of mine, thinking about the idea of collocated Team work areas, remarked that when he was a child and had been bad, his parents put him in a corner. He had to face away from everyone and be in isolation. He couldn ‚ t help but notice the parallel between this
for being bad and what we do to our most
When people are asked to achieve the possible, they will often try. When people are asked to try to do a little more than the possible, they will continue to try if they aren ‚ t punished for not achieving everything. When people are given all the help they need and ask for, when people are encouraged and treasured, they almost always respond by doing their best.
When people work by
, they can achieve great things. When people work with others, they often achieve synergy, where the joint effort far exceeds the sum of the individual efforts. In my experience, this exponential increase in productivity continues until a Team
seven people, give or take two. At that point, the shared work, vision, and concepts start to require additional support, such as documentation. Regardless of the scaling mechanism, above a modest number like seven, the productivity of a Team starts to decline, the miscommunications increase, the mistakes proliferate, and frustration grows.
Scrum is for achieving results in complex situations. Using practices such as the Product Backlog, the results can be optimized to the situation. But Scrum is also very much about people. ScrumMasters become dedicated to their teams because
are neighborhoods that people, including the ScrumMaster, live within.
When I last visited Service1st, it was a good place to visit. I could watch people striving to improve the organization, the teams, themselves, and their profession. I was proud to be associated with them. I have helped implement Scrum in hundreds of organizations over the last
, and I found this to be a reasonable outcome to anticipate. What more can you ask from life?
Scaling Projects Using Scrum
Many projects require more effort than a single Scrum Team can provide. In these circumstances, multiple Teams can be employed. Working in parallel, the efforts of these
are coordinated through a variety of mechanisms that range from formal to ad hoc. When more than one Scrum Team works
on a project, it is referred to as a
, and the mechanisms employed to coordinate the work of these teams are called
. Every scaled project has its own complexities, each of which usually requires its own unique solution. Scrum
in the same manner as any other development process, using practically the same scaling mechanisms, while retaining all of the empirical practices that form its
. This chapter provides guidelines for scaling projects using Scrum; these patterns are ones that I ‚ ve used successfully on nearly a hundred projects. But keep in mind that scaling can be difficult, and remember that this chapter doesn ‚ t offer any magic formulas or foolproof prescriptions.
The kernel around which all scaling occurs is the Scrum Team. An 800- person project will consist of one hundred 8-person teams. In this chapter, we ‚ ll examine how to coordinate the work of these teams while maintaining the productivity of each individual Scrum Team. We ‚ ll also examine how to scale projects regardless of the number of people they involve, as well as the type of application, the type of system, the number of places in which development is to occur, and other relevant scaling dimensions. In this chapter, I will
the employment of Scrum scaling practices in a mission-critical project where the pressure to scale to a large project was
. In this case, the scaling had to support multiple teams working simultaneously on one software system from multiple geographic locations.
Scaling at MegaFund
We ‚ ve
at MegaFund in previous chapters. MegaFund had a pressing business problem that it wanted to solve as quickly as possible. If you were a MegaFund customer in 1997 and wanted to transfer money,
an account, trade stock, or take advantage of any of MegaFund ‚ s other financial offerings, you had two choices: you could either pick up the telephone and call an agent or go to the MegaFund office in the
metropolitan area and use a dumb 3270-type terminal connected through a network to MegaFund ‚ s mainframes. Although this technology had been innovative in the 1980s, MegaFund
now let customers manage their accounts
from their home or office computers,
phones, Web-based devices,
, and telephone voice-response units, at any time and on any day. The pressure to correct this competitive disparity and provide competitive technology was immense at MegaFund. Everyone at MegaFund wanted to start his or her own project and immediately build a competitive offering.
MegaFund Systems Company (MSC) provided technology services to MegaFund. MSC determined that the best way to support the new competitive products was to link them to its legacy databases through middleware servers. Every organization would write its own business functionality to run on the servers, and MSC would write common data access capabilities. The servers would be designed to support virtually any transaction
in a secure, restartable environment. These goals constituted the first nonfunctional requirements that were put in the Product Backlog.
The Product Owner wanted to initiate many teams so that solutions could be delivered as soon as possible. However, if architecture with adequate details wasn ‚ t present first, the work couldn ‚ t be cleanly divided among the multiple teams. If a development environment supporting multi-site source code management and build processes wasn ‚ t set before work began, the multiple Teams would get out of sync and would likely create conflicting code. And if standards weren ‚ t defined before work
, the interfaces between the business and data objects would likely be inconsistent. Consequently, we defined a nonfunctional Product Backlog to
and construct such a scalability infrastructure. All of these nonfunctional requirements were given top priority.
We then added a small number of functional business requirements. The account management organization wanted customers to be able to directly access their accounts and review
and previous transactions over the Web. We broke these requirements down into smaller pieces and parsed them among the nonfunctional requirements, planning to build part of the account management functionality every Sprint while
the scaling infrastructure and materials in place. To staff this team, we selected some of the best designers and
at MegaFund. Because the Product Backlog required standards and infrastructure development, we also staffed the team with writers and infrastructure and build
. As a result, the team was somewhat oversized at 10 people.
At the end of the first Sprint, the team demonstrated a single account management transaction: the team showed existing balances, working from a Web browser, through transaction-specific business objects, to information-specific data objects, through the legacy databases, and back. The team then demonstrated the transaction after restarting the server, as would happen in the event of a crash. Several team
showed scalability figures
the performance of this single transaction across multiple transactions on clusters of the selected server technology. In sum, the team demonstrated that its approach was
by using it to successfully execute a business transaction.
The Product Owner and other stakeholders were so
that they wanted to immediately create more teams and set them loose on this project. However, the initial team required two more Sprints to complete the scaling infrastructure, so it wasn ‚ t until the fourth Sprint that more teams were created. There were now seven teams sprinting, each of which was
with someone from the initial team who was charged with providing expertise and guidance to the rest of the team. Each team
Daily Scrums, which were followed by a ‚“Daily Scrum of Scrums ‚½ at which the members of the initial team met as representatives of their new teams to synchronize the work of these seven new teams. The Daily Scrum of Scrums followed the same format as a regular Daily Scrum.
This MegaFund project delivered
business functionality from the very first Sprint. Even though three Sprints were required before we could scale the project to seven teams, the stakeholders in the project saw progress being made on their problem from the start. They had to hold themselves back from scaling too quickly, but they were never left feeling that important progress wasn ‚ t being made. The Teams delivered business value to the Product Owners at every Sprint review, and the Product Owners were beside themselves with delight. Sometimes it is difficult for teams to break down complex technical or business problems into something that can be demonstrated within a Sprint, but I ‚ ve yet to see a team fail this challenge.
It is worth underscoring several Scrum practices used in this example that are critical to the success of any scaling effort. First, build the infrastructure for scaling prior to scaling. Second, always deliver business value while building the infrastructure. Third, optimize the capabilities of the initial team, and then staff the additional teams with at least one member of the initial team. These practices are described in more detail in the