Just as there are many reasons why some people will resist Scrum, there are many ways someone might resist. One person may resist with well-reasoned logic and fierce arguments. Another may resist by quietly sabotaging the change effort. Still another may resist by quietly ignoring the change, working the old way as much as possible, and waiting for the next change du jour to come along and sweep Scrum away.

Each act of resistance carries with it information about how people feel about adopting Scrum. As a change agent or leader in the organization, your goal should be to understand the root cause of an individual’s resistance, learn from it, and then help the person overcome it. There are many techniques you can use for doing this. But unless the technique is carefully chosen, it is unlikely to have the desired effect. To help select the right technique, I find it useful to think about how and why someone is resisting. We can group the reasons why someone is resisting Scrum into two general categories:

• They like the status quo.
• They don’t like Scrum.

Reasons for resistance fall into the first category if they are actually a defense of the current approach. This type of resistance to changing to Scrum would likely result no matter what type of change was being contemplated. Reasons fall into the second category if they are arguments against the specific implications of beginning to work in an agile manner.

Categorizing how individuals resist is even simpler: Is the resistance active or passive? Active resistance occurs when someone takes a specific action intended to impede or derail the transition to Scrum. Passive resistance occurs when someone fails to take a specific action, usually after saying he will.

The figure below combines the whys and hows of resistance into four general types of resistance, each with a name descriptive of the person who resists in the way indicated by the labels on the axes.

A skeptic is someone who does not agree with the principles or practices of Scrum but who only passively resists the transition. Skeptics are the ones who politely argue against Scrum, forget to attend the daily scrum a little too often, and so on. I am referring here to individuals who are truly trying to stop the transition, not people with the healthy attitude of “this sounds different from anything I’ve done before but I’m intrigued. Let’s give it a try and see if it works.”

Shown above the skeptics are the saboteurs. Like skeptics, saboteurs resist the transition more from a dislike of Scrum than support for whatever software development process exists currently. Unlike a skeptic, a saboteur provides active resistance by trying to undermine the transition effort, perhaps by continuing to write lengthy up-front design documents, and so on.

On the left side of the figure are those who resist because they like the status quo. They are comfortable with their current activities, prestige, and coworkers. In principle, these individuals may not be opposed to Scrum; they are, however, opposed to any change that puts their current situation at risk. Those who like the status quo and who actively resist changing from it are known as diehards. They often attempt to prevent the transition by rallying others to their cause.

The bottom left of the figure shows the followers, who like the status quo and resist changing from it passively. Followers are usually not enraged by the prospect of change, so they do little more than hope it passes like a fad. They need to be shown that Scrum has become the new status quo.

When introducing a complex change into a large organization, resistance will be inevitable. What isn’t inevitable is the reaction of an organization’s leaders to that resistance. In a 1969 Harvard Business Review article, Paul Lawrence describes an appropriate response to resistance.

When resistance does appear, it should not be thought of as something to be overcome. Instead, it can best be thought of as a useful red flag—a signal that something is going wrong….Therefore, when resistance appears, it is time to listen carefully to find out what the trouble is. What is needed is not a long harangue on the logics of the new recommendations but a careful exploration of the difficulty.

While its important to confront resistance, be careful not to create an atmosphere of “us” against “them.” The real goal is to create a feeling that the transition to Scrum is inevitable and that, as the Borg of Star Trek taught us, “resistance is futile.” The need to foster this atmosphere does not give you carte blanche to ignore the feelings and reactions of employees or to steamroll Scrum into an organization. Instead, to paraphrase Nigel Nicholson in a 2003 article for the Harvard Business Review, when an employee resists, an effective leader looks at the employee not as a problem to be solved but as a person to be understood.

For more help with overcoming obstacles to your agile transition, see Chapter 6 of Succeeding with Agile.

A community of practice is a like-minded or like-skilled group of individuals who voluntarily come together because of their passion and commitment around a technology, approach, or vision. On a large project, these communities of practice are helpful for cutting across the boundaries of and pulling together individuals from the many crossfunctional teams. An example can be seen in the figure below.

The figure above shows communities of practice formed simply around various project roles. In addition, a sufficiently large project might have communities of practice form around technologies (a Ruby community and a .NET community, for example), around interests (mock objects, artificial intelligence, test automation), or around any thread of common interest to multiple development teams. A good example of a community of practice is the Virtual Architecture Team at Salesforce.com, as described by Eric Babinet and Rajani Ramanathan.

The Virtual Architecture Team (VAT) is “virtual” as it is made up of developers from every Scrum team. Members work on the VAT in addition to being on a Scrum team. The VAT owns maintaining and extending our industry-leading software architecture. They do this by defining the architectural road map, by reviewing architecturally significant changes to the code, and by defining standards to ensure consistent and maintainable code.

Communities of practice can span more than one project. For example, a community of practice around test automation may form and include members from multiple, completely unrelated projects. Because they span teams, communities of practice are a primary mechanism for spreading good ideas among teams and for ensuring desirable levels of consistency or commonality across a set of development teams. A community of middle-tier programmers might, for example, discuss and decide when would be the best time to upgrade to the latest version of application server software for a family of products. Discussions among members of an orthogonal test team would ensure consistent test tool usage and the sharing of good practices.

The most effective type of community of practice within Scrum organizations seems to be one that forms organically rather than by management request, although both approaches can be used for different purposes. Because self-organization is critical to successful agile teamwork, the formation of self-organizing communities of practice creates a powerful synergy. In this sense it is up to the organization and its leadership to create an environment in which communities of practice can form, flourish, and then fade away as they run their course. If you want communities of practice to form organically, you may need to provide some encouragement. Potential community members will need to know that it is OK—and in fact encouraged—for them to form communities. I’ve encountered a few situations where managers and executives gave their Scrum teams a great deal of leeway in self-organizing and were left wondering why no communities of practice formed. When I asked the team members about this, they told me they were under the impression that such informal groups would be frowned upon by management. Make sure your team members know that such cross-team communities are not only OK but encouraged.

No matter which agile project management approach you are using, communities of practice are well worth the time and investment. The service they provide in aiding communication and coordination across a large organization or a large project is invaluable. If communities of practice have not yet formed in your organization, start one around a topic that interests you or is causing your organization pain. As that community begins to contribute to the organization, other communities are likely to form as well.

Additional advice on cultivating communities of practice and on specialized communities, such as improvement communities and the enterprise transition community, is provided in Chapters 4 and 17 of Succeeding with Agile.

Although team members should always look to share with one another their newly discovered good ways of working, they should resist the urge to codify them into a set of best practices. What’s good for one team may be too prescriptive for others. For example, one company I visited had decided that all daily scrums needed to be held no later than 10:00 a.m. I found this an extremely unnecessary dictate. I’m not entirely sure what purpose the dictate served, but many employees interpreted it as a lack of trust by their management.

Even a good practice can lure teams into a false complacency once it has been established as the “best.” Like sirens singing to us from the rocks, best practices can tempt us to relax and stop the effort of continuous improvement that is essential to Scrum. Mary Poppendieck quotes Taiichi Ohno, originator of the Toyota Production System, as saying that “there is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over.” Ohno goes on to say that if we establish something as the “best possible way, the motivation for kaizen [continuous incremental improvement] will be gone.”

In Scrum, sharing success stories and methods that work is a good idea. Establishing one set of solutions as the best is not. Don’t limit the very improvement you are seeking. Instead, let your organization’s standards evolve with you as you grow more agile.

For more information on this topic, see Succeeding with Agile: Software Development using Scrum.

I started reading a new book called Made to Stick by Chip and Dan Heath. It’s about why some ideas are “sticky” and spread while other ideas die out. They start with the classic urban legend of the guy who is drugged and wakes up in a bathtub full of ice and discovers his kidney has been stolen. That’s a sticky idea. Many of us have heard it, and we remember it after hearing it. Sticky ideas and stories aren’t necessarily bad; they are just things that change our attention at just the right time and that are so intriguing/compelling/interesting that they spread like wildfire.

This got me thinking about sticky stories from my past and how perhaps stickiness has changed given the rapid communication of today, including and especially the Internet. One real story from my life is from back in January 1981. I was in college and living in the dorm. Ronald Reagan was newly sworn-in as President. A common joke at the time was that Reagan would start a nuclear war and blow up the whole world. The previous summer the US had boycotted the Olympics because of the Russian invasion of Afghanistan. It was a bit of frightening time.

That’s why I remember how scary it was one Sunday morning when our whole dorm woke to rumors that the US and the USSR had declared war on one another. We couldn’t confirm this, though. Not a single person in our dorm had a TV. None of the radio stations were saying anything about it. This was before Al Gore had invented the Internet. This rumor of US-USSR war was *sticky.* It spread around the whole dorm building within minutes. People were waking others, pounding on their doors saying, “Wake up, we’ve declared war on Russia!” Still, we couldn’t get any real confirmation of this.

I finally called my parents who lived two timezones away and were still asleep. I sheepishly asked, “Mom, did we declare war on Russia this morning?” She thought I was crazy so I explained. While I did that she turned on her television and confirmed nothing was being reported. That was good enough for us. All of us college students went back to sleep.

Two thoughts strike me form this: First, Communication has changed that much in 27 years. It was possible back then to be unable to verify something like a war. If that happened today I’d browse the web on my phone and know in seconds. Second, that was a very first-hand example of how quickly a sticky idea could spread.

It seems that agile might be a sticky idea.