Chapter 3. Patterns for Adopting Scrum

There are many different routes an organization can take to adopt Scrum. Fortunately, from looking at companies that have already transitioned, we are able to identify some common patterns of how to do it successfully. In this chapter, we look at the strengths and weaknesses of four patterns, as well as when each may be appropriate. The four patterns form a pair of questions that must be addressed at the start of any Scrum adoption effort. These questions are as follows:

• Should we start with one or two teams, or should we convert all teams at the same time?

• Should we announce our intent (perhaps just to others in the company but perhaps publicly as well), or should we keep the change quiet for now?

In addition to providing guidance for answering those two questions, we explore three options for spreading Scrum after the initial effort is underway. Finally, the chapter concludes by considering how soon a new Scrum team should begin focusing on adopting agile technical practices.

Start Small or Go All In

Conventional, long-standing advice regarding transitioning to Scrum or any agile process has been to start with a pilot project, learn from it, and then spread agile throughout the organization. This approach is the frequently used start-small pattern in which an organization selects typically one to three teams (of five to nine people each), gets them successful, and then expands Scrum from there. As Scrum spreads through the organization, new teams benefit from the lessons learned by the teams that have gone before. There are many variations of start small, depending on how many people the organization wants to transition and how quickly they want to do it. Start small can also be applied differently based on how risk-averse or uncertain about the transition the organization is. For example, in some cases the first team or teams will finish their projects before a second set of teams even begins. Other organizations will take an overlapping approach, where the second set of teams starts only one or two sprints after the first.

The start-small pattern, while popular, is not for everyone. Salesforce.com, for example, followed the opposite pattern (Fry and Greene 2006). I remember answering my phone on October 3, 2006, and hearing Chris and Steve from Salesforce.com tell me that they had just converted 35 teams to Scrum overnight. They asked if I’d like to help. My initial thought was that they needed a psychiatrist more than a Scrum consultant. Not one to shrink from a challenge, though, I agreed to help, packed a copy of Freud alongside my laptop, and set off for their office in San Francisco. Part of what I saw there wasn’t entirely unexpected—teams and individuals in an uproar over such a sudden, far-reaching change—but I also saw other things that helped this large-scale, rapid adoption succeed.

Salesforce.com was pursuing the all-in pattern, which draws its name from a poker player who bets all of his chips on one hand. Salesforce.com has a hard-driving, aggressive, achievement-driven culture that would not have been a good fit for a cautious start-small approach. When key executives were presented with a proposal to adopt Scrum, they were convinced. They felt that if Scrum was worth doing for one team, it was worth doing for all teams, so they chose to go all in.

Surprisingly, the all-in and start-small patterns can be combined. An increasingly common approach is a one- to three-team pilot project followed immediately by going all in. The pilot in this case serves the typical purpose of allowing the organization to learn about Scrum and how it will function there. However, the pilot in this scenario also serves the more important purpose of increasing organizational awareness about Scrum. If you’re going to transition 200 or more people all at once, it is extremely helpful to be able to point to one team who has already done it and say, “We’re all going to do what they did.”

Reasons to Prefer Starting Small

The start-small approach offers several advantages.

• Starting small is less expensive. An all-in transition will almost certainly cost more than starting small. Because of the greater number of people learning a new way of working all at the same time, all-in transitions generally rely more heavily on outside coaches, ScrumMasters, and trainers. The slower pace of a start-small adoption allows the organization to build internal expertise and then use that to help the teams that start later. Starting small also saves money because early mistakes affect only a subset of the organization. Tom Gilb, who was perhaps the original agilist, has written, “If you don’t know what you’re doing, don’t do it on a large scale” (1988, 11).

• Early success is almost guaranteed. By carefully selecting the initial project and team members, you can almost guarantee the success of your first Scrum project. You may consider this cheating; I don’t. When starting small, a goal of the first few projects is to generate the knowledge that will enable the successful rollout of Scrum. There may be value in starting with a project and team that make success easy and then learning from its experiences. Additionally, an early success can be vital to gaining buy-in from skeptics or fence-sitters.

• Starting small avoids the big risk of going all in. An all-at-once transition can be very risky. Small mistakes will be magnified across the entire transition effort. Perhaps the most significant risk to an all-in approach is that you will be unlikely to get a second chance. If you start to transition the entire organization, make a mistake that increases resistance, and then revert to your pre-Scrum process while figuring out how to overcome the newly discovered issues, it is unlikely that team members will give you a second chance to start the transition. Resistance by that point will likely be so entrenched that the transition effort will have failed. By contrast, if you start small and find a fatal flaw in how you’ve started, you can keep the next round the same size as the current one, rather than expanding, effectively restarting the transition process.

• Starting small is less stressful. Twenty-first century organizations and their employees are under constant stress. An announcement that the whole development organization is adopting Scrum, which affects so many aspects of everyday work, could be the proverbial straw that breaks the camel’s back. The stress of transitioning is reduced by starting small because early adopters become coaches and ambassadors. They encourage other groups to make the transition with stories of their successes and honest discussions of the challenges they faced and overcame.

• Starting small can be done without reorganizing. Most organizations that fully adopt Scrum will eventually undergo some degree of reorganizing. This can create further stress and can increase resistance from some individuals. By starting small, the need to reorganize can be put off longer, ideally until valuable experience with Scrum has been gained.

Reasons to Prefer Going All In

Just as there are reasons to prefer starting small, there are reasons to prefer an all-in transition:

• Going all in can reduce resistance. In anything less than an all-at-once transition, there will always be some skeptics who will hold out hope that the whole effort is a pilot that will soon be abandoned. Like Cortez burning his boats at Vera Cruz to prove his resolve to his soldiers, an organization that goes all in is demonstrating both its commitment to the new process and also that it will not turn back. This level of visible commitment to the change can be beneficial in helping the change succeed.

• It avoids problems created by having Scrum and traditional teams work together. If you transition anything short of the entire company all at once, you run the risk of having some teams using Scrum and others not. This means there will be times when a Scrum team needs to coordinate work with a traditional team, which creates challenges because of the different attitudes Scrum and traditional teams bring to things like planning, deadlines, and communication. These problems go away when the entire organization adopts Scrum at the same time. Chris Fry and Steve Greene of Salesforce.com report that “the key factor driving us toward a big-bang rollout was to avoid organizational dissonance and a desire for decisive action. Everyone would be doing the same thing at the same time” (2007, 137).

• An all-in transition will be over more quickly. One of the central tenets of this book is that an organization is never “done” becoming agile; there are always improvements to be made. However, there is definitely a time when employees can look back and say of the transition that the worst is over. An organization that goes all in can reach this point more quickly.

Choosing Between Going All In and Starting Small

As I mentioned at the start of this chapter, starting small has been the default approach recommended by most agile authors and used in most agile adoptions. The combination of this approach’s low risk and high likelihood of success make it hard to find fault with. Always choose to start small when there is a reluctance by leaders in the organization to fully commit to Scrum. Success, even on a small scale, can be the best way to convince the skeptics. Always start small when there is a high cost associated with failure. If the cost of failure is too high for those leading the transition, starting small is the way to go, even if it may not be best for the organization as a whole. Start small is probably not the best approach when your organization urgently needs the benefits of Scrum. (But if you do choose to start small, scale quickly.) Starting small is safe, but it’s slow.

Going all in should be used in limited cases. Consider going all in if time is critical. Although an all-in approach may cost more money, it will cost less time. If time is your primary concern, all in may be the best solution. Consider going all in if you, like Salesforce.com, want to send a clear message to a small number of critics and stakeholders that Scrum is here to stay. Never go all in without enough experienced ScrumMasters to serve each team. It doesn’t matter in the short term whether these ScrumMasters are internal or external; but remember that eventually you’ll want all of your ScrumMasters to be internal employees. Finally, size matters. If there are only ten of you, you might as well go all in. But for teams of more than perhaps 400, going all in may not be logistically possible.

Whichever route you choose for adopting Scrum, remember that choosing this pattern is only the first of the many decisions you’ll need to make when transitioning. You will next need to decide whether to make your transition public.

Public Display of Agility or Stealth

The next choice to make is whether or not to publicize your transition. One option is to make a public display of agility. In this approach, the team or organization announces with great fanfare that it is adopting Scrum. Depending on the scope and significance of the transition, the announcements may range from lunchroom comments to other teams all the way up to press releases in the national media. No matter the extent of the publicity, with a public display of agility, teams make an effort to inform others that something agile is going on.

In contrast to a public display of agility is a stealth transition. In a stealth transition, only the team members know they are using Scrum until the project is complete. I found a group doing a stealth transition at one of my clients. On my first visit to this client, I spoke with Sarah, the director of the company’s project management office. She told me that the transition to Scrum was well underway. It had begun shortly after I delivered a two-day training class to many developers in its headquarters office. Sarah shared with me a well-thought-out plan she had outlined to introduce Scrum across her company’s more than 200 developers.

Sarah’s plan showed four initial pilot teams, each of which had been selected for specific reasons. One team was chosen for its willingness to relocate into a shared team space very different from the dedicated cubicle environment in use at the time. Another team was chosen because it would be one of the first to use a new technology in which the company was making a significant investment. The other two teams were selected to be part of the pilot for equally good reasons. Sarah’s plan was great because it would enable teams to maximize the learning right from the outset of this transition effort.

I left Sarah’s office planning to visit each of the four teams so that I could get their perspective on how things were going. Strangely, though, I didn’t find four teams—I found five. When I figured out which of the five wasn’t one that Sarah had told me about, I went back and talked with that team some more. I discovered that it was not an officially sanctioned part of Sarah’s pilot effort. The members had noticed the goings on of one of the official teams, liked what they had seen, and decided to try it themselves. They had a vague sense that they probably shouldn’t be doing what they were doing and had placed their wall-hanging task board and burndown chart well inside a labyrinth of cube walls. I had only stumbled across it because I was unfamiliar with the building and had gotten lost looking for one of the official teams.

This team was doing a stealth transition. Members were using Scrum but were keeping their activities to themselves until the project was complete. There are varying degrees of stealth—some teams may actively try to keep what they’re doing quiet while others merely don’t publicize the change.

Reasons to Favor a Public Display of Agility

There are many good reasons for making a public display of agility. Among them are the following:

• Everyone knows you’re doing it, so you’re more likely to stick with it. Standard advice to anyone attempting to adopt or abandon a habit is to solicit the help of your friends. Whether you are starting a diet, quitting smoking, or starting an exercise program, telling your friends about the change is a good idea. You’ll likely feel an unspoken pressure to succeed because you’ve announced your intentions; your friends will also be able to support and encourage you. The same is true when transitioning to Scrum.

• A public display establishes a vision to work toward. Publicly proclaiming your intent provides an opportunity to create thought and discussion around the goal. With the intent out in the open, team members will feel comfortable talking about the transition with those outside the team. They’ll be able to share successes and failures. Those interested in the transition (perhaps wishing they could be part of it) will offer advice; those opposed will offer resistance. A public display can provide the opportunity to engage both groups, providing the opportunities to encourage the former group and to overcome the objections of the latter.

• Operating in the open is a firm statement of your commitment. A stealth transition can be perceived as a bit wishy-washy. It is as though the team or organization is saying, “We believe in this but we want to hedge our bets by having the chance to back away if it doesn’t go well.” There’s no backing away from a public display. It makes a powerful statement that not only does the organization plan to initiate the transition, but it also plans to be successful at it.

• You can solicit organizational support. If you’re trying to keep the use of Scrum quiet, you’ll have limited ability to reach outside the team for assistance. There are many obstacles you may encounter as you transition; before abandoning the assistance of possible allies in overcoming them, make sure the advantages to stealth are compelling.

• Stating your goal and then achieving it sends a powerful message. Announcing at the end of a project that the project was successful because it secretly used Scrum is much less compelling to skeptics than telling them up front. Baseball player Babe Ruth’s most famous home run was the 1932 “called shot.” With a count of two balls and two strikes, Ruth pointed to the centerfield fence and hit the next pitch into the centerfield bleachers. Saying what you’ll do and then doing it is more powerful than announcing your goal after it has been achieved.

Reasons to Favor a Stealth Transition

Stealth transitions may seem a bit sneaky, but there are actually quite a few advantages to keeping a low profile. These include

• You have a chance to make progress before resistance starts. A public announcement about the transition will bring resistors and naysayers out of the woodwork. Their best chance to avert the change is before it gains much momentum, and so they will argue strongly against it after it is announced.

• A stealth transition keeps additional pressure off. If adopting Scrum is a high-publicity affair with proclamations in company newsletters, the intranet, and so on, the team can feel a great deal of pressure to succeed—both at the project and at the transition. For teams that thrive under pressure this might be good. However, when the project is finished you won’t know if it had been successful because of Scrum or because of the additional pressure the team was under. Bob Schatz and Ibrahim Abdelshafi did not announce a grand change of process when they led Primavera’s successful transition to Scrum.

One of the first things we didn’t do was start telling everyone that we planned to use a new process. We didn’t want to make people apprehensive, and we wanted to give them time to adjust to the changes. Plus, when you run around announcing your new process and all its benefits, you can quickly set unrealistic expectations. (2005, 37–38)

• No one knows about it until you tell them. When operating in stealth mode, you can wait until the project is successful before indicating that the project was run in a different way. Or, if the project fails, you can adjust how you are doing Scrum, try again, and only tell people after you’ve figured out the nuances of doing so that lead to success in your environment.

• If no one knows you’re doing Scrum, no one can tell you to stop. If you start so quietly that no one but the individuals involved know, there’s no one who can tell you to stop. I’ve seen individual teams choose the stealth approach under the premise of it being easier to ask forgiveness than permission. I’ve also seen vice presidents of development or project management offices choose to introduce Scrum in stealth mode so that they could prove tangible benefits before having to debate the merits of Scrum with groups they knew would resist.

Choosing Between a Public Display and Stealth

I find that organizations willing to make a public display of agility are more likely to enjoy a successful transition than those that try a stealth approach. Always choose to make the transition publicly known when you are confident in Scrum and committed to the transition. Similarly, strongly consider a public display if you expect there will be stiff resistance to the change but want to overcome it quickly.

In contrast, choose a quieter approach when you want to experiment either with all of Scrum or just parts of it. For example, maybe you introduce daily meetings—don’t call them daily scrums in this case—and see how that works. Then introduce the idea of working in timeboxed sprints. If these go well, maybe start calling what you’re doing agile or Scrum and proceed from there. Additionally, always choose a stealth approach when it is your only option. If you don’t have the political clout to say, “We’re doing Scrum,” or if doing so will create too much resistance, start quietly.

Patterns for Spreading Scrum

Getting started with Scrum is one thing; spreading it across the organization is another. Unless you have chosen an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum into other teams. There are three general patterns you can use for spreading Scrum beyond the initial teams. The first two patterns involve taking a team that has begun to be successful with Scrum and then using its members to seed new teams. The third pattern takes a different approach and involves spreading Scrum using internal coaches.

Split and Seed

The split-and-seed pattern is typically put into use after the first couple of teams have adopted Scrum and run at least a handful of sprints. By that point, team members are beginning to understand what it is like to work on a Scrum team. They certainly won’t have figured everything out, but sprints should be ending with working software, and team members should be working together well. In short, the team probably has a long way to go to get good, but Scrum is starting to feel natural.

It is at this unlikely point that we split the team up.

In the split-and-seed pattern, one functioning Scrum team is split in two, with each half of the original team forming the basis of a new team. New people are then added to these splinter teams to form new Scrum teams. This pattern is shown in Figure 3.1, which shows the creation of two teams from one original team. A large initial team could be used to seed as many as four new teams, especially if the initial team included some members with previous Scrum experience or a natural aptitude for it.

Figure 3.1 The split-and-seed pattern applied to two initial teams.

The new team members can be either newly hired employees or existing employees moving onto their first Scrum projects. The idea behind the split-and-seed pattern is that newly formed, second-generation Scrum teams will have an easier time learning the mechanics and practices of Scrum because they will have guidance from the experienced members of the team. The new teams are left together for a few sprints until that team begins to jell and its new members have developed a feel for Scrum. Then, again, the functioning teams are broken up into smaller teams and new members are added to fill out the teams. This cycle is repeated until Scrum has been fully introduced.

In a large, enterprise rollout of Scrum, you do not need to leave each generation of teams together for the same number of sprints. You can instead split each team whenever it’s ready.

Grow and Split

The grow-and-split pattern is a variation of the split-and-seed approach. It involves adding team members until the team is large enough that it can be comfortably split in two, as shown in Figure 3.2. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size range of five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes large enough that it can also be split. This pattern repeats until the entire project or organization has transitioned.

Figure 3.2 The grow-and-split pattern used to create two teams.

Internal Coaching

Philips Research’s Scrum adoption is an example of the third pattern for spreading Scrum: internal coaching. Philips had begun adopting Scrum and was facing a problem. Like many organizations, it had some teams that were excelling with their new agile approach and others that were struggling. Philips’ Christ Vriens solved the problem by using internal coaching. On each team that was doing well, he identified one person who truly understood what it meant to be agile and designated that person as a coach to another team that had not yet progressed as far in its understanding and use of Scrum.

Coaches were given specific responsibilities, such as attend sprint planning, review, and retrospective meetings; attend one daily scrum each week; and be available for two hours each week to provide other assistance to the mentored team as needed. Coaches were not excused from their responsibilities on their original teams, but it was acknowledged that each coach would have fewer hours to contribute to those teams.

Reasons to Prefer Split and Seed

The split-and-seed pattern’s advantages are rooted in its quick-spreading nature.

• You can add teams more quickly than with most other approaches. Each new team should ideally include at least 2 members of the previous team. This means that possibly as soon as after 2 or 3 sprints, a team of 8 people could conceivably be split into four 2-person groups used to seed a second set of teams. If each of those 4 teams had 8 people you would have 32 Scrum team members. A few sprints later these 32 people could be used to seed 16 more teams, each with 8 team members for a total of over 100 Scrum-experienced people after only 5 or 6 sprints.

• Each team has someone with Scrum experience to help guide them. Only the very first teams to transition will be forced to do so without someone on the team with Scrum experience. All subsequent teams will benefit from having at least two (and hopefully three or four) team members with at least a couple of sprints of experience under their belts. This can help reduce the discomfort some people will feel about transitioning to something new and unfamiliar.

Reasons to Prefer Grow and Split

The grow-and-split pattern spreads Scrum a bit more slowly than does the split-and-seed approach but comes with some key advantages.

• You don’t have to destroy any existing teams. The primary problem with the split-and-seed strategy is that teams who are just starting to jell and get a handle on Scrum are demolished to form the basis of new teams. Breaking up a good team is always something that should be done with caution. Growing the team before splitting it overcomes this shortcoming because the team is kept together until it is large enough to form two complete teams, each with agile experience.

• Team members feel more continuity from sprint to sprint. When using the split-and-seed pattern, teams are constantly being split and reformed before a true sense of team camaraderie is established. Because the grow-and-split approach divides a team only when it has gotten too big, members can stay together longer, and there is less feeling of disruption.

Reasons to Prefer Internal Coaching

The internal coaching approach is generally my preferred approach. Not surprisingly, there are a strong set of advantages to it, including the following:

• Well-running teams do not need to be split. A drawback to the prior patterns is that functioning teams are split to form the foundations of new teams. When using internal coaches, teams stay intact with only the minor disruption of an occasional outsider (the coach) joining the team.

• Coaches can be hand-selected for new teams. An approach like the split-and-seed pattern takes a whole-team approach to coaching: The new team is coached collectively by the seeding team members. Some of those individuals will be good in that role; some will not. With internal coaching, the most appropriate coach can be selected for each new team.

• Coaches can be moved from team to team. After awhile a team and its coach become stale. A fresh pair of eyes can be helpful in identifying new ways to improve. When internal coaches move from team to team they act like bees, pollinating each team with new ideas.

Choosing Your Approach

There are two driving factors in choosing among these three patterns for spreading Scrum: How quickly do we need to spread Scrum to additional teams, and do we have good internal coaches who can assist the new teams? The answers to these questions will be key to helping you choose the pattern that best fits your organization.

In general, consider using split and seed when you are in hurry. The split-and-seed approach can be one of the fastest ways to spread Scrum through an organization. The approach can be accelerated in a couple of different ways: First, you can split teams a bit earlier than might be ideal. Second, you can split teams into more new teams than might be ideal, perhaps four new teams instead of two, even if this means that some new teams get some less-than-ideal coaches from the earlier teams.

Be cautious, though, about using split and seed if the technology and domain cannot support moving people among teams. Changing team membership is always detrimental to productivity. That loss can be offset, however, by the benefits of quickly spreading Scrum through a large project or organization. However, in some cases, it is just not practical to move people between teams. For example, seeding a .NET team with Java programmers just because they have three sprints of Scrum experience would not be a good idea.

The grow-and-split pattern is perhaps the most natural approach, as it mirrors what would probably happen if no one intervened to help the spread of Scrum. In most organizations, people move between projects, carrying good practices with them. The grow-and-split approach is simply a more directed approach than letting this happen naturally, which would take much, much longer.

Consider using grow and split when there is not enough urgency to push you to the split-and-seed approach. Because growing and splitting a team is a less aggressive (and less risky) approach than splitting and seeding a team, it is often used in similar situations but when there is a bit less urgency. Also consider using grow and split when the team size is growing anyway. True to its name, the grow-and-split approach works best when teams are expanding.

Internal coaching can be used as a spreading strategy on its own, or it can be used to augment either of the other approaches. This approach works best under certain conditions:

• When the group is large enough that good practices won’t fully spread on their own. One of the strengths of this pattern is that coaches can move from one team to another, spreading good practices as they do so. If your organization is small enough that sharing good practices won’t be a problem, then you may not need this approach.

• When splitting teams is not practical for your projects. If any of the drawbacks to splitting teams concern you, the internal coaching approach is a good antidote.

• When you have enough internal coaches or can bring in outside help. An ideal coach is someone who fundamentally understands Scrum and has probably worked in an agile way for years before even hearing the word. These individuals can be hard to identify in advance; they aren’t necessarily the most experienced team members. If you don’t have enough good coaches, consider using one of the other patterns initially. After enough teams have run a few sprints, you can begin to augment a seeding approach with internal coaches. You can also spread the coaches you do have out a bit more by having each coach assist more than one team. If budget allows, you can also bring in outside consultants until you have built up your internal coaching corps.

Introducing New Technical Practices

One final decision facing change agents, ScrumMasters, and new Scrum team members themselves is how soon the team should adopt new technical practices. One school of thought is that everything should start with the technical practices. If a team is using the right technical practices—simple design, automated testing, pair programming, refactoring, and so on—then agility will be the natural result.

The alternative view is that a team should be left alone longer and given time to discover the technical practices that work best in its environment. ScrumMasters, managers, and coaches may eventually nudge a team toward trying different practices. “Would this have happened if we had more automated tests?” a Scrum-Master might ask the team. But in general, the team is given longer at the start to work without pressure to adopt or even try specific new technical practices.

In this section, we’ll consider both the reasons to encourage an early start at trying new technical practices and the reasons why delaying might be a better choice.

Reasons to Start Soon

There are three very good reasons for putting an early emphasis on adopting new technical practices:

• Very rapid improvements are possible. Many of the technical practices can provide some quick wins to the team and organization. Pair programming, for example, can help cross-train programmers across more areas of the system. Introducing a continuous build process can reduce integration hassles to near zero. Other practices—test-driven development, for example—have steeper learning curves, but even these are measured in days and weeks rather than months and years.

• If the team doesn’t try new technical practices early, it might never try them. Too many Scrum teams adopt the bare minimum of Scrum and stop there, deciding that the improvements already achieved through their new iterative and incremental work style are sufficient. By not considering or trying new or improved technical practices, these teams forgo much of the improvement they could have made. I tend to think of such teams as having learned to work iteratively but having not become agile. Gabrielle Benefield reports having witnessed this problem at Yahoo! while she was the company’s director of agile product development.

The most visible symptoms of dysfunction in Yahoo! product development were at the project and team layer (centered around issues of planning, project management, release management, and team interactions), rather than at the technical practices or tools layer. As a result, Yahoo!’s initial focus was on the adoption of Scrum. There was active debate about whether agile engineering practices should also be adopted in parallel; in hindsight, it would have accelerated the benefits had they been. (2008, 461)

• It may address the project’s most pressing issues. Introducing a team to the agile technical practices can solve an array of typical project problems, including poor quality, over-engineered solutions, long delivery cycles, and so on. There are other problems, though, that are not addressed by introducing these practices. For example, a project with a disengaged product owner will experience slow or incorrect decision making. This problem will not be remedied solely by introducing new technical practices. The same is true for a project with multiple product owners, each with a competing agenda, or for a project with strong personality clashes among team members. If your project’s most pressing issues are ones addressed by one or more of the common agile engineering practices, consider emphasizing those practices early in the transition.

Reasons to Delay

Just as there are strong reasons for encouraging a team to adopt new engineering practices early, there are also reasons why it may be better to wait:

• There may be strong resistance to some practices. Introducing certain technical practices can be one of the most difficult challenges you face when transitioning. Many individuals are extremely reluctant to try new things, such as simple design, pair programming, and test-driven development. Although you may have good reasons to push the team to try new practices close to the outset, they will need to be weighed against the risk of increased resistance.

• Team members may already have their hands full. Just learning the fundamentals of working on a Scrum team can be challenging in many organizations. The added stress of also learning new technical practices may simply be too much for some teams, causing them to shut down and not try. Given enough time, the pressure of delivering working software within Scrum’s strictly timeboxed sprints may bring these same teams to the realization that they need to try new technical practices.

One Final Consideration

This chapter presented two questions that will confront any organization transitioning to Scrum: Start small or go all in? Public display of agility or stealth? Answers do not need to be binary—there is a great deal of middle ground between starting small and going all in for most organizations. The patterns for spreading are similar. They can be used on their own or combined as needed to fit your particular circumstances. Perhaps, for instance, you first decide to split and seed, but as time passes, and enough teams exist, you can slow down and let teams grow before splitting them, while also speeding learning through the use of internal coaching. In addition, no matter what pattern you choose, leaders of the transition effort (and those participating in it) must address how much to change at any one time for the team or teams transitioning. Attempt to change too much and teams are disoriented; change too little and you risk exhausting people through a marathon of small changes.

Joshua Kerievsky, a senior consultant with the Cutter Consortium, is in favor of enacting all changes at once. He is opposed to what he calls “piecemeal transitions” because he says they

• Are more painful because the change process is protracted

• Fail to address root problems

• Rarely lead to complete transitions

• Produce changes too slowly for the business to benefit from

• Tend to be done without expert help, resulting in making easily avoided, costly mistakes (2005)

Although Kerievsky raises some good points, they ultimately derive from thinking of the transition to agile as a one-time thing that can be completed. On the contrary, adopting an agile approach such as Scrum is a process of continuous improvement. There is no predefined end state. Because of this, it is incorrect to talk about a “complete transition” or a change process that takes too long. Change is no longer something organizations “go through.” Change is now a perpetual, ongoing occurrence.

Writing in the Agile Journal, Liz Barnett presents a different view than Kerievsky’s.

Starting slow is the way to go. For the vast majority of companies interested in agile practices, incremental adoption represents the most pragmatic way to improve their software development organizations while managing risk. As they implement organizational, process, and technology changes, teams can continually reassess their progress and determine the most pragmatic next steps. It’s the agile way to become agile. (2008)

Kent Beck and Cynthia Andres, authors of Extreme Programming Explained, agree, acknowledging the near necessity of starting with a subset of practices and new ways of working and then improving one thing at a time.

It’s easy to start by changing one thing at a time. I think it’s hard to jump in and do all the practices, embrace all the values, and apply all the principles in novel circumstances by reading this book and deciding to do it. The technical skills in XP and the attitudes behind them take a while to learn. XP works best when it is done all together, but you need a starting place. (2004, 55)

This brings us to our next chapter. After you’ve decided to transition to Scrum, understood the ramifications of change, and made your decisions regarding the pattern you are most likely to emulate, it’s time to begin making the changes Scrum requires. As Beck and Andres so aptly point out, the best way to do that is iteratively. We explore how to use the Scrum framework, along with specialized communities of practice called improvement communities, to adopt and spread Scrum, bring about continuous improvement, and transfer agile ideas throughout the organization.

Additional Reading

Beck, Kent, and Cynthia Andres. 2005. Getting started with XP: Toe dipping, racing dives, and cannonballs. PDF file at Three Rivers Institute website. www.threeriversinstitute.org/Toe%20Dipping.pdf.

Beck and Andres use entering a pool to describe three different approaches for adopting Extreme Programming. Toe dippers enter slowly, adopting one practice at a time. Cannonballers make a big splash and deal with the sudden chaos it creates but transition quickly. They describe a racing dive as an “assisted cannonball,” referring to doing a lot of changes quickly but with guidance from an experienced coach.

Benefield, Gabrielle. 2008. Rolling out agile in a large enterprise. In Proceedings of the 41st Annual Hawaii International Conference on System Sciences, 461–470. IEEE Computer Society.

This paper provides detailed information on Yahoo!’s large Scrum adoption effort. Details on both what was done right and what could have been improved are included.

Elssamadisy, Amr. 2007. Patterns of agile practice adoption: The technical cluster. C4Media.

This book, which is available as a PDF through www.infoq.com, focuses on the technical practices that should be adopted by agile teams. As such, it is complementary to the patterns presented in this chapter.

Hodgetts, Paul. 2004. Refactoring the development process: Experiences with the incremental adoption of agile practices. In Proceedings of the Agile Development Conference, 106–113. IEEE Computer Society.

This paper summarizes Scrum trainer Paul Hodgetts’ experiences from transitioning a handful of teams to agile. He contrasts the advantages and disadvantages of incrementally adopting agile with adopting it all at once based on experiences with those projects.

Striebeck, Mark. 2006. Ssh! We are adding a process.... In Proceedings of the Agile 2006 conference, ed. Joseph Chao, Mike Cohn, Frank Maurer, Helen Sharp, and James Shore, 185–193. IEEE Computer Society.

Mark Striebeck describes how agile was introduced to the AdWords front-end application at Google. He describes the combination of a start-small and stealth approach, with new practices added incrementally.