Category list

Conclusions

When Service1st started using Scrum, the organization consisted of individuals working on their assigned tasks 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 punishment for being bad and what we do to our most valuable assets, our employees .

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 themselves , 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 reaches 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 teams 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 decade , and I found this to be a reasonable outcome to anticipate. What more can you ask from life?

Chapter 9: 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 Teams are coordinated through a variety of mechanisms that range from formal to ad hoc. When more than one Scrum Team works simultaneously on a project, it is referred to as a scaled project , and the mechanisms employed to coordinate the work of these teams are called scaling mechanisms . Every scaled project has its own complexities, each of which usually requires its own unique solution. Scrum scales 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 core . 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 demonstrate the employment of Scrum scaling practices in a mission-critical project where the pressure to scale to a large project was intense . 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 looked 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, open 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 nearest 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 competitors now let customers manage their accounts themselves from their home or office computers, cell phones, Web-based devices, pagers , 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.

Approach

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 volumes 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 began , the interfaces between the business and data objects would likely be inconsistent. Consequently, we defined a nonfunctional Product Backlog to devise 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 balances 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 putting the scaling infrastructure and materials in place. To staff this team, we selected some of the best designers and architects at MegaFund. Because the Product Backlog required standards and infrastructure development, we also staffed the team with writers and infrastructure and build engineers . 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 members showed scalability figures extrapolating 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 viable by using it to successfully execute a business transaction.

The Product Owner and other stakeholders were so delighted 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 seeded with someone from the initial team who was charged with providing expertise and guidance to the rest of the team. Each team conducted 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.

Lessons Learned

This MegaFund project delivered valuable 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 next section.