Patterns for Adopting Scrum - 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 riskaverse 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 Fd 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 ofSalesforce.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 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.

Source of Information :  Pearson - Succeeding with Agile Software Development Using Scrum 2010

ADAPTing to Scrum

Lori Schubring was among the first to realize that things had to change. An application development manager for a large manufacturing company, Lori realized that its development process had become "so formalized that we hindered our ability to remain flexible for the business. It got to the point where we weren't turning around project requests fast enough" (2006, 27). Aware of the need to change, Lori attended a free, half-day seminar introducing Scrum. What she saw there was a better way to develop software, a framework she thought might help her organization. As such, Lori developed the desire to change to Scrum. Next, she acquired the ability to do it by participating in a ScrumMaster class, attending an agile conference, and visiting a company that had already adopted Scrum. Lori then promoted Scrum to her boss and team, convincing them of its benefits. Finally, Lori transferred some of the implications of her team using Scrum to the rest of her company so that organizational gravity would not pull the team back to where it had started.

Lori's story encapsulates the five common activities necessary for a successful and lasting Scrum adoption:

� Awareness that the current process is not delivering acceptable results

� Desire to adopt Scrum as a way to address current problems

� Ability to succeed with Scrum

� Promotion of Scrum through sharing experiences so that we remember and others can see our successes

� Transfer of the implications of using Scrum throughout the company

Conveniently, these five activities�Awareness, Desire, Ability, Promotion, and Transfer�can be remembered by the acronym ADAPT. These activities are shows Awareness, Desire, and Ability as overlapping, whereas Promotion and Transfer repeat and occur throughout the transition effort. After you have transitioned, this cycle will continue as you continuously improve.

The five activities of ADAPT are based on ADKAR (Hiatt 2006), a general model of change that includes the steps of Awareness, Desire, Knowledge, Ability, and Reinforcement. In practice, I have found separating Knowledge and Ability to be unnecessary. In a field such as software development, knowledge without ability is meaningless. Additionally, the Reinforcement step of ADKAR is replaced in ADAPT with separate Promotion and Transfer steps, emphasizing the importance of these activities to a successful transition.

An organization that successfully adopts Scrum can be thought of as engaging in these activities at multiple levels:

� Organizationally. The organization as a whole will engage in these activities. No matter how aware one person or group is, there must be a critical mass of people with a similar awareness before the organization will be able to collectively move forward. In thinking of the ADAPT model at this level, we may speak of a company with an organizational desire to adopt Scrum. Or we may say that our organization currently lacks the ability to do Scrum.

� As individuals. Because organizations are made up of individuals, it is important to acknowledge that individuals will progress through the overall transition at different rates. For example, you personally may already have acquired the ability to do Scrum; you've learned some new skills and some new ways of thinking about software development. A colleague, on the other hand, is only starting to become aware that the current approach isn't working.

� As teams. Individuals can be aided or hindered in the transition to Scrum by their teams. Teams tend to progress through the ADAPT cycle more or less together. In the same way that studies have shown individuals are more likely to be overweight if their friends are overweight (Thaler and Sunstein 2009), you are more likely to have a desire to do Scrum if the rest of your team does as well.

� Per practice. The ADAPT model can also be applied to each new skill that is acquired as part of adopting Scrum. Consider the increased reliance on automated unit testing that is common on Scrum teams. The team and its members must first become aware that the current approach to testing isn't working. They must then develop the desire to automate more tests and to do so earlier in the process. To do this will require that some team members learn new skills. Promoting the team's success with automated testing will encourage other development teams to emulate them. Finally, transferring the implications of the team doing more automated testing to other groups ensures that forces external to the team do not prevent it from continuing with the new practice.

One of the first things you'll need to do, whether you are currently using Scrum or just starting your adoption, is to decide where your individuals, teams, and organization are in their ADAPT sequence. It could be that you are acquiring the ability to do test-driven development on a team that is promoting its success inside a department that desires to implement Scrum. The overall organization, however, may be aware of only a general need to change. This chapter will discuss not only the five ADAPT activities but also the tools you will need to encourage and develop awareness, desire, ability, promotion, and transfer throughout all levels of the organization.

Source of Information :  Pearson - Succeeding with Agile Software Development Using Scrum 2010

Why Becoming Agile Is Hard (But Worth It)

Many software development organizations are striving to become more agile. And who can blame them? Successful agile teams are producing higher-quality software that better meets user needs more quickly and at a lower cost than are traditional teams. Besides, who wouldn't want to be more agile? It just plain sounds good, doesn't it? It is almost as though one cannot be too thin, too rich, or too agile. But beyond the buzzword and hype, organizations that take becoming agile seriously by adopting a process such as Scrum are seeing dramatic benefits.

They are seeing significant gains in productivity with corresponding decreases in cost. They are able to bring products to market much faster and with a greater degree of customer satisfaction. They are experiencing greater visibility into the development process, leading to greater predictability. And for them, out-of control, will-it-ever-be-done projects have become a thing of the past.

One company to realize these benefits by adopting Scrum is Salesforce.com. Founded in 1999 in a San Francisco apartment, Salesforce.com is one of the true, lasting dot-com-era success stories. With revenue of more than $450 million and 2,000 employees in 2006, Salesforce.com had noticed the frequency of its releases had dwindled from four a year to one a year. Customers were getting less and waiting longer to get it; something needed to be done. The company decided to transition to Scrum. During the first year of making the switch, Salesforce. com released 94% more features, delivered 38% more features per developer, and delivered over 500% more value to its customers compared to the previous year (Greene and Fry 2008). In the ensuing two years, revenue more than doubled to more than $1 billion. With results like these, it is not surprising that so many organizations have transitioned to Scrum. Or at least tried to.

I say "tried to" because transitioning to Scrum and other agile methods is hard�much harder than many companies anticipate. The changes required to reap all of the rewards being agile can bring are far reaching. These changes demand a great deal from not only the developers but the rest of the organization as well. Changing practices is one thing; changing minds is quite another. It is my aim in this book to show not only how to transition well but also how to succeed long term.

I've personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an "Agile Office" to which new Scrum teams could turn for advice. The company's failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.

For completely different reasons, Josef ultimately failed at introducing Scrum to his company. A newly promoted and first-time project manager, Josef was instantly attracted to Scrum because it fit his natural management style. Josef easily convinced his team�who had all been his peers as little as one month before�to try Scrum on their new project. The project was wildly successful, earning accolades for the team and winning Josef the chance at a much larger project. Josef introduced the new project team to Scrum, and most members were willing to try the new approach. Although those working on the project were happy to use Scrum, some of the functional managers to whom they reported got nervous about what Scrum might mean to their careers. Josef's luck ran out. The functional managers�in particular the directors of quality assurance and database development�banded together and convinced the vice president of engineering that Scrum was inappropriate for projects of the complexity and importance being done in their company.

Caroline fared a little better. A vice president of development in a large data management company, Caroline had more than 200 developers in her organization. After seeing the benefits of Scrum on one project, she excitedly launched an initiative to introduce Scrum across her division. All employees were provided with training or coaching. Within a few months nearly all teams were producing working software at the end of each two-week sprint. This was great progress. When I visited this company a year later, though, the employees had failed to make any additional headway. To be sure, teams were producing higher-quality software and doing it a bit faster than they had before starting with Scrum, but her company's gains were only a fraction of what they could have been. Caroline's company had forgotten that continuous improvement is part of Scrum.

Frightening, isn't it? Each of these failures was a well-intentioned effort to transition to Scrum.Yet all the good intentions in the world could not keep them from failing. Don't worry, though. Transitioning to Scrum may be hard, but it's entirely possible with the right approach. In this chapter we examine why transitioning to any agile development process, including Scrum, is especially difficult.

We detail some of the challenges that derailed the companies I've mentioned. Most important, though, we look at the reasons why the benefits of becoming an agile organization are more than worth the effort.

Source of Information :  Pearson - Succeeding with Agile Software Development Using Scrum 2010