Chapter 2. 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 also summarized in Figure 2.1, which 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.

1 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.

Figure 2.1 The five activities of adapting to Scrum.

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.

Awareness

Change begins with an awareness that the status quo is no longer desirable. However, becoming aware that what worked in the past is no longer working can be extremely difficult. The most dramatic example of this I personally experienced was when I was a development director for a healthcare software company back in the mid-1990s. Our company founder recognized that the company’s sole product—the one that had led to an extremely successful public offering and tremendous growth in the company—had at most one year of sales left because of the fundamental shift occurring at the time in the United States healthcare industry. Our company would need to develop a new product that could capitalize on the shift toward managed care. In a meeting of the entire company, our founder presented a slide with the chart shown in Figure 2.2.

Figure 2.2 The “Valley of Death” shows declining revenue from the current product in advance of the release of a new product.

While most employees had been congratulating ourselves on our success, which we anticipated would last forever, our founder realized we were entering what he called the “Valley of Death.” While in the Valley of Death, revenue from the current product would quickly decline well in advance of increases in revenue from the new product we hadn’t started developing yet.

Few of us can be as prescient as this company founder was. There is almost always a lag between when the need to change first arises and when we become aware of it. The lag can be particularly long if the company is doing well. Other common reasons why individuals can be slow to develop an awareness of the need to change include the following:

• A lack of exposure to the big picture. The need to adopt Scrum may be the result of a confluence of factors not visible to everyone. The need for a change may be apparent only to those who have seen the decline in sales to new customers, heard the rumors of a strong competitor entering the company’s space, and anticipate the need to do more without adding staff.

• A refusal to see what’s right in front of us. Even when the need to change is clear, we sometimes deny it. We may think the problems are temporary and often fear what change may have in store. The “if it ain’t broke, don’t fix it” mentality is about as far as can be from an agile “if it ain’t perfect (and it never will be), keep improving” mindset.

• Confusing motion with progress. Every day we see a flurry of activity. Meetings are being held, status reports are being circulated, documents are being written, and code is being checked in. It is easy to confuse all of this motion with progress. When a lot is happening, it can be hard to admit that all that activity is not leading us any closer to the desired products.

• Listening to our own propaganda. The company newsletter is full of rahrah articles predicting the boundless future. The glass case in the lobby proudly displays past Product of the Year trophies. Hallways are full of gleeful, self-congratulatory chatter. Yet customers ask, “What have you done for me lately?” Listening to our own cheerleading and propaganda causes complacency. By all means, celebrate success but remember the hard work that earned it.

Tools for Developing Awareness

Team members will become aware of the need to change at different times. Those who have come to this realization quickly have the opportunity to assist in bringing others along to the same conclusion. In this section we will look at tools you can use to help develop awareness of the need to change.

Communicate that there’s a problem

BioWare is one of the world’s leading developers of story-driven video games, with more than 400 employees and well-known games such as Mass Effect, Jade Empire, Dragon Age, Knights of the Old Republic, Neverwinter Nights, and Baldur’s Gate. Although BioWare’s products had been successful, the projects to deliver them were not very efficient. Projects were afflicted by the usual symptoms of overtime, communication issues, and deliverables that occasionally failed to meet expectations.

Because of its strong track record of successful products, it wasn’t obvious to all involved that the projects themselves could be more successful. Fortunately, producer Trent Oster’s search for a better way to develop games led him to Scrum, and he was able to hire several project managers with Scrum experience. But this nucleus of early Scrum proponents could not make much progress until they helped others become aware of the need to improve. They did this by communicating a goal that would be shared by all projects.

High-quality games at a lower cost that are as fun to develop as they are to play

This goal was wonderful for a couple of reasons. First, it is very hard to argue with. I can’t imagine a team member arguing that it was as fun working all those long nights as it was playing the game that resulted. Second, it neither preached nor proposed the solution. Consider the likely impact if BioWare’s early Scrum advocates had instead chosen “High-quality games built with an agile approach.” This would have convinced no one of the need to change except for those already in favor of it. William Bridges, author of Managing Transitions, stresses the importance of selling the problem, not a specific solution to it (2003, 16).

Use metrics

As part of an overall communication strategy, metrics provide great reinforcement of the core reasons for change. I have seen companies use employee turnover, results from job satisfaction surveys, revenue per employee, and other simple metrics to convey the message that change is necessary.

Provide exposure to new people and experiences

Encourage people to attend conferences or training so that they hear about new techniques and practices. Or send people to a trade show for your industry. Let them see what products competitors are releasing. Or arrange meetings between team members and customers so they can hear firsthand about what features are needed and in what time frame. A good long-term strategy for providing exposure to new people and ideas is to value diversity in new hires. Intentionally seeking people from different backgrounds helps not only bring new ideas into the organization when they’re hired, but it also helps the organization with exposure to future new ideas.

Run a pilot project

A successful pilot project demonstrates that things can be better. It is hard to argue with success. When those who aren’t yet aware of the need to change see a highly successful project run in a different way, they must either discount the results on that project or become a bit more aware that a change could be appropriate.

Focus attention on the most important reasons to change

If your organization is like most others, you could probably create a lengthy list of reasons why the current development process is broken: Products do not meet user expectations, products take too long to develop, quality is poor, developer morale is low, overtime is excessive, schedules are unpredictable, the cost of development is high, and so on. In helping people become aware of the need to change, it is often best to replace such a laundry list with one that is much shorter. What two or three reasons are causing most of the problems? These reasons alone should be sufficient to justify adopting Scrum. By narrowing the full list of reasons down to just the critical ones, we focus more attention on the most compelling reasons.

One of my clients decided to adopt Scrum because its products had lost their best-in-class status. Customers were continuing to use the products but mostly out of years of loyalty and familiarity. To focus attention on this problem, I asked them to remove all plaques, trophies, and industry awards from the lobby except those earned within the past year. By removing old Product of the Year awards from the lobby, we reinforced the fact that customers were asking “but what have you done for me lately?” After the old mementos had been removed, the lobby still showcased a decent number of awards. But the contrast with what employees had become accustomed to was startling and helped increase the awareness that the company’s glory days were behind it unless changes were made.

Desire

Beyond being aware of the need to change, one must also have the desire to change. I am aware that I should eat more vegetables; I don’t yet desire to make that change in my diet. Until my awareness turns to desire, my diet will remain the same. Scrum trainer and consultant Michele Sliger tells of a company whose transition was stalled by a similar lack of desire. A few weeks after a training class, Sliger called the company to see how people were doing.

Due to the politics at their company, they decided that agile really wouldn’t work there. That’s the only group I know that took the time to learn about agile (from an experienced agile consultant and not just a book), really examined their culture and politics, and then said “No.” Were they being practical? realistic? or were they being fearful? pessimistic? I don’t know. But no other company I’ve worked with has ever said no like that. Perhaps more should. I really respected the fact that these people decided that they weren’t ready, for whatever reason, rather than making some half-hearted attempt.

Because they’d gone to the expense of bringing a Scrum trainer into the company, at least some employees must have been aware of the need to do things differently. But from Sliger’s story we can conclude that there was insufficient desire to take the change effort further.

Moving from an awareness that the current development process isn’t working to the desire to use a different one can be very hard for many people. After all, we’ve been educated to prefer a sequential approach, both through our schooling and years of experience. Additionally, although we may be dissatisfied with elements of our projects, we’ve worked hard to get the right boss and the right team. Scrum would change all that. Finally, as simple as it may seem, sometimes the timing may just not be right.

Twenty years ago a friend of mine recommended I read one of the Travis McGee novels by John D. MacDonald. I bought The Girl in the Plain Brown Wrapper that evening and started reading it. I hated it and stopped halfway through. About a year later I saw the book on my shelf and decided to give it another try. I loved it and went on to read all 20 of the other books featuring McGee. Something about my mindset, where I physically was, or such, was wrong when I first read the book. The same can be true when team members hear messages about the benefits of Scrum. If the time isn’t right for people, you will not be able to convince them. The good news is that the same message delivered the same way but at a different time will often be enough to move someone along from awareness to desire.

Tools for Increasing Desire

Increasing the desire to adopt Scrum is often much harder than creating an awareness that the status quo must change. Fortunately, there are many tools for moving people from awareness to desire.

Communicate that there’s a better way

When building awareness, communication centers on the key problems facing the organization or team adopting Scrum. After we shift from building awareness to increasing desire, communication then focuses on how Scrum can help address those problems. Mixing the two messages (that the current approach isn’t working well enough and that Scrum can help) can cause some people to shut down and become unreceptive to either message. However, as more employees become aware of the need to change, the change agent’s message can shift to one of evangelism. Lori Schubring, whose story started this chapter, writes of the contagious nature of desire.

I was convinced agile could help us. I put a plan together, got support from our director, and became the internal evangelist. Because I believed so strongly, it was tough for anyone to ignore. If people challenged the idea, I challenged them right back. My desire caught on to some, others came along a little less willing. A few key people took interest, and that really helped the rest of the group open up to the possibilities of Scrum.

Create a sense of urgency

One way to turn awareness into desire is to turn up the heat. By creating a sense of urgency, we make it clear to others that the status quo cannot continue as such for long. Remember my awareness that I need to eat more vegetables? Suppose my doctor called tomorrow and said that I would die in six months if I didn’t start eating broccoli, asparagus, cauliflower, and the like. I would likely respond by figuring out how to like them.

Build momentum

Rather than focus on those who are reluctant or opposed to Scrum, spend your time and effort helping those who are already enthusiastic. Rather than argue what can or can’t be done, do it with those who are willing. The goal is to build an unstoppable momentum with each success leading to another. When Steve Greene and Chris Fry of Salesforce.com look back on their company’s successful transition, they advise others to “focus on getting several teams to excellence” (2008). Rather than spread support too thinly across all teams, strive to make the adoption of Scrum look inevitable through these early successes. Then others will desire to be part of it.

Get the team to take Scrum for a test drive

Rather than allow team members to argue about Scrum in the abstract, have them get some quick experience with it. Then they can discuss it and argue about specifics. A good approach is to agree to a three-month trial. This will give the team ample opportunity to get past the first one or two sprints, which are likely to still feel very uncomfortable. Hold a thorough retrospective with the entire team at the end of the three months and collectively decide how to move forward. The decision does not need to be “Scrum” or “not Scrum.” If the test drive was inconclusive or the team is divided, another option is to continue the test drive for a few more months. Or perhaps the team decides that it is not ready for a particular practice and chooses to temporarily shelve it but will otherwise continue to work with Scrum.

Align incentives (or at least remove disincentives)

There are many incentive programs, financial and otherwise, in organizations that can work against the adoption of Scrum. Many organizations have bonus programs to reward one employee for significant contributions to the team or department. Although such a program may appear beneficial at first glance, it works against the “we’re all in this together” teamwork mentality we want of Scrum team members. Bonus programs that reward testers based on the number of defects found (and logged in a defect tracking system) have a similarly debilitating effect.

One organization I worked with revised its annual review form, removing the individual-oriented criteria, such as job knowledge, time management, and ability to balance multiple priorities. It replaced them with team-oriented criteria, such as makes others better at their jobs, contributes to shared knowledge, willingness to work beyond job title, and met team deliverable and quality goals.

In another company, I got the product owner and functional managers to promise a unique nonmonetary bonus to the team if the product would be released on schedule with an agreed-upon set of features. Although the product owner and managers trusted the team to continue to do high-quality work, I asked the team members to propose a quality metric. I didn’t want them to receive their bonus by sacrificing quality. They proposed that quality would be measured by the number of defects reported in the 30 days following release. Their goal was to have fewer reported defects than two prior releases of a similar size. Four months later the team delivered slightly more functionality than promised on the planned date. When quality was measured a month later, the team members were given their bonus—a four-week sprint during which they would be their own product owners and could work on whatever they wanted. They took the opportunity to do some refactoring that had been bothering them. One tester took time to explore a new testing tool. Two developers added a scripting interface to a part of the application. This type of bonus was a win all around and avoided the problems that tend to arise with cash or similar bonuses.

Focus on addressing fear

How we behave is often influenced by what we fear. Because of bad past experiences, a product owner may fear an out-of-control development organization that builds only what it wants. This leads the product owner to prefer a development process with a detailed, up-front requirements gathering phase, as this will prevent the developers from building only what they want.

On the other hand, executive management may fear excessive schedule delays. This leads them to favor a development process that provides early, precise estimates of delivery dates. Managers almost always know they won’t get the product by the date promised. But, they reason, by getting the team to commit to an early date and by keeping the pressure on them, they will get it earlier than they would otherwise and can avoid large schedule slips.

An architect may favor doing a detailed up-front system design because she excels at this. She fears that if the project’s design phase is removed, then she will look no more brilliant than her coworkers. When communicating with individuals whose desire may be impeded by a fear, look for opportunities to address why the fears are likely unfounded.

Help people let go

People will not desire a new future until they can let go of the past. Every transition brings with it the possibility of loss, and with loss comes grief. Allow people time to grieve. Listen and accept their losses without arguing. Loss is personal and subjective. You will never convince people who are grieving that they are overreacting and that what was lost wasn’t “that important.” So don’t try.

Don’t discredit the past

In describing the transition and the brave, new agile world you are moving to, do not downplay or discredit the past. Whatever development process existed until now helped the organization succeed to the extent it has. It deserves our sincere appreciation and respect. It couldn’t have been all bad. William Bridges, author of Managing Transitions, describes the consequences of building support for new initiatives at the expense of past efforts.

Many managers, in their enthusiasm for a future that is going to be better than the past, ridicule or talk slightingly of the old way of doing things. In doing so they consolidate the resistance against the transition because people identify with the way things used to be and thus feel that their self-worth is at stake whenever the past is attacked. (2003, 34)

Engage employees in the effort

Enlist as many allies at this stage as possible. An ideal ally is an opinion leader who has earned the respect of a large part of the audience you are targeting. The infectious enthusiasm of a few opinion leaders can rapidly spread to others in the organization. Benoit Houle, a ScrumMaster with BioWare, experienced this firsthand.

I was very fortunate to establish a great working relationship with one of the senior programmers on the team who was very respected. He was the ScrumMaster of our initial “pilot” Scrum team for several sprints. He got extremely excited about the process and bought numerous books about Scrum and Extreme Programming. He did a great job as a ScrumMaster, and his enthusiasm was echoing in every corner of the office.

Get skeptics involved as well. Ask employees what they would need to see, experience, or know before wanting to try Scrum; then find ways to give it to them.

Ability

All of the awareness and desire in the world won’t get a team anywhere if it does not also acquire the ability to be agile. As we touched on briefly in Chapter 1, “Why Becoming Agile Is Hard (But Worth It),” succeeding with Scrum requires team members not only to learn new skills but also to unlearn old ones. Some of the larger challenges Scrum teams will face include the following:

• Learning new technical skills. It is common for developers new to Scrum to discover that while they are still good at their jobs, they aren’t yet good at being agile. They will have to develop skills they didn’t require previously (or could justify ignoring). For example, programmers will need to learn how to evolve the design of a system. Testers often must learn how to test a system without as much reliance on documentation. Both usually need to learn new ways of automating tests.

• Learning to think and work as a team. Many of us have enjoyed years of working silently in a cubicle, headphones securely on, with as little team interaction as possible. “You develop your part; I’ll develop mine. We’ll talk if we find any problems when we integrate.” Scrum teams are encouraged not to think in terms of my tasks and your tasks but of our tasks. This forces collaboration among team members to new highs. Working in this way also creates a mindset of shared responsibility that will be new to many team members.

• Learning how to create working software within short timeboxes. Scrum’s short, focused, timeboxed sprints present significant challenges to most teams who are new to working that way. Scrum teams strive to avoid unnecessary handoffs from one specialist team member to another. Developing working software by the end of each sprint will challenge team members to find ways to eliminate wasteful handoffs and to work more closely with each other.

Tools for Developing Ability

In most organizations, developing the ability to become agile (and then becoming good at it) will take longer than building awareness or creating desire. Fortunately, there are many good tools for developing ability, including the following:

Provide coaching and training. Scrum is sufficiently different from traditional software development in that training along with on-site coaching or mentoring is usually required. Lori Schubring, who led a successful Scrum adoption, says, “Our ability to be successful with agile started with an educational process. In my opinion, that was key. If we didn’t understand something, we couldn’t possibly welcome it with open arms.” Elizabeth Woodward, one of the leaders of IBM’s agile adoption, concurs.

We initiated our agile transformation by setting a goal to conduct instructor-led two-day Disciplined Agile Development classes at every major site world wide within the first quarter. Within the first three quarters, we had taught over 4,400 software engineers world wide. This was important for getting everyone on the same page, for sharing the vision, and for building a sense of urgency. We found that there was misinformation about agile that needed to be addressed in order for teams to more willingly embrace agile.

What seems to work best for most companies is some initial training, oriented at creating a willingness to try Scrum and to understanding its core principles. This general training is usually then followed up with practice-specific training or coaching, such as bringing a test-driven development expert on-site to work hands-on with teams in their code.

Shortly after initiating its Scrum adoption, Salesforce.com had me do an on-site training course for more than 30 ScrumMasters, including some individuals who would not be in that role on projects. Two months later it had me do a formal, two-day training session for 35 product owners. Additional on-site coaches were also brought in to work with the teams during this period. In hindsight, even with this early and strong commitment to training and coaching, Chris Fry and Steve Greene wish they had “trained product owners earlier and with more intensity” and that they had gotten “outside coaching earlier.” They offer the following advice to companies transitioning to Scrum: “Get professional help” (2008).

Hold individuals accountable. Along with providing coaching and training, employees need to know they will be held accountable for applying the new skills the organization is paying them to acquire.

Share information. While developing the ability to be agile, team members will be awash with new information and challenges. Provide opportunities for them to share information and problems. One way to do this is by cross-pollinating teams: Encourage team members to occasionally attend another team’s daily scrum meeting or sprint review. Another option is to make use of the departmental intranet, Wikis, communities of practice, and reading groups to disseminate information. Yet another avenue for sharing is to ask those who have learned a new skill to present a short training session on it to others. Or, if your group is large enough, go further and have a day-long miniature agile conference. This is exactly what Yahoo! did in its California headquarters. J. F. Unson, a Scrum coach with Yahoo! at the time, describes the approach.

At Yahoo! we had a full-day internal open space conference, where anyone could come in and propose topics. We had a number of good sessions, especially ones dealing with enterprise adoption, distributed agile, and so on. We had folks as far as the UK schedule meetings around the open space and participate. It really helps to build community within your company and get people to come up with and own their solutions. Of course, it helped that as a company we had critical mass to generate enough participation. (2008)

IBM takes a similar approach, conducting two four-day meetings each year that include technical leaders and managers from around the world plus the technical staff at the local site. Elizabeth Woodward describes how the company conducts a number of smaller “mini-conferences” around the world for IBM employees adopting agile.

Each of those meetings has focused on agile, with presentations, education, experience reports, and community working sessions on agile topics. The working sessions were particularly productive because we were able to address key challenges such as using Scrum in a distributed environment, with face-to-face debate and discussion from a diverse, experienced group of people.

Set reasonable targets. Presented with a goal such as “be agile now,” many teams freeze, not knowing how to start. A successful Scrum transition needs to be split into smaller pieces. So rather than asking a team to “start doing test-driven development,” the ScrumMaster should ask the team to develop one feature that way in the next sprint. Similarly, organizations must balance a push for rapid progress against the risk of pushing for too much too quickly. By encouraging teams to select realistic, actionable targets, you can help them avoid the hesitation that can occur before initiating any immense undertaking.

Just do it. Don’t stall, waiting to know all the answers before you start. The best way to develop the ability to do something is to start doing it. As Greene and Fry advise, “Experiment, be patient, and expect to make mistakes” (2008).

Promotion

There are three goals during promotion. The first is to lay the groundwork for the next pass through the ADAPT cycle. By promoting current successes you will have a jump start on creating awareness for the next round of improvements. The second goal is to reinforce agile behavior on existing teams by spreading the news of the good things those teams have achieved. Finally, the third goal is to create awareness and interest among those outside the groups directly involved in adopting Scrum. Many of those groups (such as human resources, sales, marketing, operations, and facilities) can have a dramatic influence on the success of your transition. In the transfer phase, you will actively pursue making sure that such groups will not pull the development organization back away from an agile mindset.

In seeking to promote Scrum, avoid turning your efforts into a marketing campaign. Many employees have been through countless change initiatives. The endless parade of such initiatives has left them jaded. Employees in many organizations have learned that if they don’t like one change initiative, wait; another will soon follow to replace it. An announcement that “we’re going agile” is likely to result in derisive comments and skepticism.

A good way to counter this cynicism is to avoid naming the transition effort. Teams that have lived through the “Quality 2000” initiative that was followed by “Better, Faster, Cheaper” and then “Customers First!” will not respond well to the “Scrum and Proud of It” campaign. Organizational development expert Glenn Allen-Meyer says that organizations name and brand their change initiatives because this type of marketing is what most organizations do.

When people at work hear the marketed messages of change, they know they must either commit, comply, or leave. When they do not see the value-adding features of the change, and they feel they must comply in order to keep their jobs, then the difference between their true feelings and their compliance creates a detachment—a schism—between themselves and their place of work. (2000c, 24)

Getting coworkers to commit to a Scrum transition effort rather than merely comply with it (perhaps waiting for it to blow over) is what we would like to achieve with a successful promotion. One of Allen-Meyer’s recommendations is to keep the change process nameless (2000a). My experience from the transitions I’ve directly managed, participated in, or observed confirms this.

One benefit to pursuing a nameless transition process is that it is harder to resist what you can’t name. Thomas, a team leader at a very large commercial software developer, experienced this. After reading some of the early books and articles on Scrum, Thomas thought it would be a good fit for his 40-person project. Without any training or access to people with experience, he introduced Scrum to the team. Employees were receptive and agreed to try. The team openly promoted the fact that it was doing Scrum as there was no reason to hide it. Unfortunately, it misunderstood a few key elements of Scrum and failed miserably.

When I met Thomas, he was still interested in Scrum and had continued reading about it and learning more. Since his failed project, he’d attended a conference and a two-day training class. Eighteen months had passed since the team’s failed attempt at Scrum, and Thomas felt ready to give it another go. So did his team. Despite failing earlier, team members had gotten enough of a glimpse of the benefits that they were willing to try again. Unfortunately, the unique vocabulary of Scrum—ScrumMaster, sprint, product backlog, daily scrum, and even Scrum itself—had taken on negative connotations within the organization. Thomas knew he would not be able to tell his boss they were going to use Scrum again. He told his boss that they would instead use “agile.” (Note the lowercase a rather than the capital A, which would have again implied a brand.) Thomas and his team went on to successfully apply their version of “agile,” which was Scrum without the giveaway vocabulary.

Tools for Promoting Scrum

Having established that coming up with an effective naming strategy and matching T-shirts is one tool we won’t use to promote the change process, let’s turn our attention to some tools we can use.

Publicize the success stories

As always, communication plays a key role during the promotion activity of the ADAPT cycle. It is especially important to broadcast the successes of the early adopters of Scrum within the organization. A study by McKinsey & Company found that in successful change efforts, the emphasis was on encouraging employees to build on successes rather than on having them fix problems (2008). Promotional activities help shift employees’ energy away from all the problems they uncovered during awareness and focus them instead on the successes they have been able to achieve.

A great way to communicate success is through internal experience report presentations from teams that have already adopted Scrum. Nothing beats hearing from someone who is already doing it. These experience reports can be combined with a general “Introduction to Scrum” presentation so that those unfamiliar with Scrum can learn not only what Scrum is but also hear one team’s story of using it. If teams have begun collecting metrics, those can be included in the presentations as well. Early metrics may be nothing more than a survey showing the percentage of people who enjoy using Scrum, the percentage who think it has made them more productive, and the percentage who think quality is higher. Later you can add more rigorous metrics.

Fortunately, the best way to promote the transition to Scrum requires no effort on your part. As Benoit Houle, ScrumMaster at BioWare, puts it: “Like viral marketing, the best vehicle was word of mouth. The staff who worked on an agile team praised the process—greater team ownership, more predictability, less wasted effort and crunch time. Others heard and wanted to be part of it.”

Matt Truxaw, a development manager and agile advocate at First American CoreLogic, had a similar experience.

I liken the agile process to a whirlpool that builds over time, sucking in new people and groups as it builds. We started with limited buy-in from the developers themselves. By regularly talking about it and helping to promote the successes, we got more developers excited about the process. Working both from within the teams and providing coaching and guidance to the project management group, we gained acceptance across most of that team.

Host an agile safari

One of my favorite ways to promote Scrum comes from Google. Team members who are curious about agile but who haven’t had the opportunity to work on an agile team are allowed to go on an “Agile Safari.” When employees go on safari, they join an agile team for a couple of weeks to get a feel for what agile is like and how it works. They experience agile “in the wild” rather than merely reading about it. I really like this idea because it addresses a concern Machiavelli identified 500 years ago when he wrote that people “do not truly believe in new things unless they have actually had personal experience of them” (2005, 22).

Attract attention and interest

Shamelessly seek attention. The more often people hear about Scrum (or better, see it or experience it), the better you will be doing at the goal of making its ultimate adoption seem inevitable. A few months into her department’s transition, Lori Schubring attracted attention to the effort in a novel way.

We also held an “Open House” on Halloween for the business to come visit our department and see what we were doing with Scrum. We created a Scrum-themed crossword puzzle and gave away prizes. We put up posters explaining the different aspects of Scrum such as the Scrum Board, Burndown Chart, Product Backlog, and ScrumMaster. We gave away prizes and provided food and beverages. The internal information services staff helped make the food and decorate the building, and the event was a huge success.

In their book Fearless Change, Mary Lynn Manns and Linda Rising point out that providing food is always a good idea. Not only will you get more attendees, they are likely to be in a better mood (2004). Benoit Houle brought food to sprint reviews at BioWare to encourage broad attendance at those meetings, which he says were “a great way to promote the successes. Everyone in the company was invited to attend.” Houle also successfully used team rooms and walls full of index cards detailing the work of the sprint to attract attention and interest.

Our war rooms full of 4″ × 6″ cards, team composition pictures, and burndown charts were also quite communicative of our team progress and accomplishments. Because of limited wall space in team rooms, we started to spread miles of corkboards within our corridors for our task boards and to show team progress and achievements.

Transfer

After three years of pushing, attending literally thousands of daily scrums himself, and running dozens of one-day “Intro to Scrum” classes for more than 500 team members, Gino had much to be proud of. Much of the development department was now using Scrum. Gino had started the company’s shift to Scrum when he was one of its many development managers. Through early results by his teams, he gained a promotion to director of a new group in the company called the “Scrum Office.” The Scrum Office provided support and services to any team that wanted help. It was similar to the project management office (PMO) of a company doing traditional software development. Gino was good in his new role and soon had more than half of the company’s development staff working on projects that were to some extent agile. Before the transition was fully realized, Gino accepted a bigger, better position at a company with bigger, harder challenges in transitioning to Scrum. Back at his old company, the Scrum adoption eventually failed—not because Gino was no longer there, but because no one (not even Gino) ever transferred the implications of Scrum outside the development organization.

I visualize Scrum as a rocket. Pushing that rocket forward is the power of its engines. But pulling it back are the forces of gravity. If the rocket is able to push far enough, it can enter into orbit. But if it cannot, it will inevitably get pulled back to earth, right where it started. The implications of Scrum must be pushed far enough into other parts of the organization so that the entire transition is not pulled back by organizational gravity.

Gino did a wonderful job of gaining acceptance for Scrum among programmers, testers, project managers, database developers, user experience designers, analysts, and so on. But the use of Scrum by more than 500 developers never led to changes in human resources, sales, marketing, or other groups. The same individual-oriented bonus and annual review programs existed. Salespeople could still promise one-off enhancements to customers without first discussing such promises with teams.

It is impossible for a development team to remain agile on its own permanently. If the implications of using Scrum are not transferred to other departments, organizational gravity from those departments will eventually stall and kill the transition effort. By this, I do not mean that the rest of the organization needs to start using Scrum. What I mean is that the rest of the organization must become at least compatible with Scrum.

Sources of Organizational Gravity

Previous sections in this chapter provided a list of tools you could use to help move your organization forward in ADAPTing to Scrum. There is really only one tool for transferring agile to other departments: communicating with those departments. So, rather than provide a list of tools, let’s look instead at the departments or groups most likely to possess a lot of organizational gravity. These are the groups that deserve attention during the transfer part of the ADAPT cycle. In working with these groups, maintain a goal of educating, not evangelizing. You want other groups to understand how the development organization benefits from Scrum. You do not need to convert them into staunch supporters of your process. Rather, you want them to understand some of its unique principles and how those might lead to friction between your group and theirs.

The following is a list of groups to whom you must transfer the implications of using Scrum. Notice that I have not included testing and product management. These groups are fundamental participants in Scrum rather than groups to which the effects of Scrum are transferred. Involvement of product owners and testers in Scrum is critical and needs to be established at the beginning of the transition effort.

Human resources

A development organization using Scrum and the human resources (HR) group are likely to clash in a number of ways. Many organizations have human resources policies that work against the successful adoption of Scrum. A periodic review process that forces managers to rank employees from most to least valuable will undermine efforts to encourage teamwork. Equally damaging is a review process that values individual contributions while ignoring teamwork.

Facilities

Tales of meddling from the “Furniture Police” are common (DeMarco and Lister 1999). Many teams are told they cannot hang index cards, burndown charts, or others signs of progress or work on the walls. Few teams are allowed to adjust their own cubicles; many have learned that the best way around this is to tear down or move cubicles over the weekend in the vein of “it’s better to ask forgiveness than permission.” Benoit Houle of BioWare has a more encouraging story of successfully transferring the implications of Scrum to his facilities group.

Facilities redesigned our floors to support agile team rooms. They built us bigger rooms to support teams of six to eight people. Our facilities team has a web application that catalogues everyone’s location and allows us to easily submit a move through our intranet. We all have the same desks, so most of the time the only items we are moving are the computer and accessories. It is quick and painless.

Marketing

In many organizations, development groups are so bad at projecting ship dates that the marketing group stops asking and just makes them up. This also happens in organizations where the marketing group is much more powerful than the development group and can therefore dictate desired dates. In transferring the effects of Scrum to the marketing group, a key focus should be on educating them about the transparency provided by Scrum.

Most marketing groups don’t like having to lock down plans a year in advance any more than development teams do. The marketing group may need to schedule an ad campaign nine months in advance. But, just like development teams, they usually prefer to have a little flexibility. Rather than specify the exact contents of the ad now, they’d prefer to commit today to running an ad but specify the exact contents of the ad closer to publication date. A Scrum team’s progressive refinement of plans combined with its strict adherence to dates should prove beneficial to marketing groups that are open to it.

Finance

The finance group often intersects with Scrum projects in two areas. First is the forecasting of project schedules and budgets. It will be important to get the finance group to understand that—regardless of the development process employed—a team cannot create an estimate that is accurate within 5% from a new product description written on a napkin. Such unrealistic requests usually come from a finance department that has been burned in the past by bad estimates from development teams. It will take time to restore the finance group’s confidence and trust in developers.

After a few Scrum teams have started to demonstrate success with the new approach, it is usually helpful to meet with your finance department. In that meeting, acknowledge past project-planning sins, but also show that while Scrum still cannot guarantee on-time delivery, it can provide early exposure to possible schedule slips.

The second area in which development and finance often intersect is in the tracking or reporting of hours. Although Scrum does not require a team to track hours worked, the team should be willing to do so if the finance department needs this information. This would be the case, for example, in a contract development company that bills customers by the hour.

Related to the tracking of hours can be a finance department’s desire to capitalize the cost of the project. Capitalizing a project refers to spreading the development cost over the projected useful life of the project rather than accounting for those costs in the month they occurred. Capitalization guidelines vary from country to country, and many of them are based on outdated concepts, including that a project cannot be capitalized until technical feasibility has been demonstrated. From past exposure to development processes, we’ve trained finance departments to think that technical feasibility is achieved after analysis and design are done. Without distinct analysis and design phases on a Scrum project, the finance group may find it hard to determine when technical feasibility has been achieved.

I’ve discussed this with many finance departments and have always been able to make the case that technical feasibility is achieved after no more than a few sprints. After all, if the team has produced working software that includes one feature from the finished product, then it must be technically feasible. While I can understand the counterarguments to this position, those arguments could also be applied to considering something technically feasible after analysis and design are done but when nothing has been coded.

There are groups beyond these to whom you will need to eventually also transfer the implications of Scrum. For example, you may work with a project management office, sales, information technology, operations, hardware development, and other groups with organizational gravity. Transferring the implications of Scrum to them will be important to your long-term success.

Putting It All Together

Like Scrum itself, ADAPTing to Scrum is iterative. It begins when some in the organization develop an awareness that the current way of working is no longer producing acceptable results. As awareness spreads, some individuals develop the desire to try Scrum in an attempt to improve the situation. Through trial-and-error, these early adopters within the organization develop the ability to be successful with Scrum. A new status quo may emerge with a small number of teams successfully using Scrum within a broader organization that does not.

As these initial Scrum teams continue to improve their use of Scrum, they begin to promote their successes—sometimes informally as might occur over lunch with friends on another team, other times more formally as in a department-wide presentation. This helps individuals on other teams begin their own progressions from awareness to desire to ability. And then soon these other teams begin to promote their successes as well.

All of this early success is nice, but it is jeopardized if adopting Scrum is viewed as something that occurs entirely within the development organization. For continued long-term success, it will be necessary to transfer the implications of using Scrum to other departments that will be affected, including sales, marketing, operations, human resources, and facilities. These groups do not need to use Scrum—we don’t need salespeople drawing burndown charts or facilities doing daily scrums. But, unless these groups make small but important changes in how they interact with the development group, they will affect the development group’s ability to be agile.

In the next chapter, we’ll explore choices among patterns you can emulate as you become able to transition to Scrum. We’ll consider whether it’s best to start small or go all in and how much promotion should occur at the beginning of the transition effort. We’ll also discuss several ways to spread Scrum beyond your initial project or projects. Understanding the ADAPT process laid out in this chapter will inform the decisions you will be asked to make in the next.

Additional Reading

Derby, Esther. 2006. A manager’s guide to supporting organizational change. Crosstalk, January, 17–19.

In this article, Esther Derby, coauthor with Diana Larsen of Agile Retrospectives (2006), presents ten insights on what a manager can do to support a change initiative. Most of the insights are focused on the awareness and desire phases.

Hiatt, Jeffrey. 2006. ADKAR: A model for change in business, government and our community. Prosci Research.

ADKAR, which is an acronym for Awareness, Desire, Knowledge, Ability, and Reinforcement, is a generic model for personal and organizational change. It served as an inspiration in creating the ADAPT model. This book offers excellent, although general, advice on awareness, desire, and ability.