People resist changing to Scrum for many different reasons. Some may resist because they are comfortable with their current work and colleagues. It has taken years to get to their current levels in the organization, to be on this team, to work for that manager, or to know exactly how to do their jobs each day. Others may resist changing to Scrum because of a fear of the unknown. “Better the devil you know than the devil you don’t” is their mantra. Still others may resist due to a genuine dislike or distrust of the Scrum approach. They may be convinced that building complex products iteratively without significant up-front design will lead to disaster.
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.
Tags: transitioning to agile
From my experiences, Skeptics can escalate into Saboteurs if not addressed. It can also snowball very quickly if upper management enables them, and in turn further undermines your team’s efforts!
-David
At what point do you decide that implementing Agile within an organization is futile?
Hi Dave–
Good point about skeptics escalating. That is indeed quite possible. Upper management demonstrating that they are committed to the transition is one of the best tools against inappropriate resistance. If people see the change as inevitable, they eventually stop fighting it.
Hi Denise–
Good question. Fortunately, I haven’t seen enough futile situations to generalize from them. I’d think though that it is probably futile when there is no passion for the change. A passionate team can introduce it and try to get others interested. Passionate leaders can motivate the team. WIthout passion from either, it’s probably futile.
I found the part about not creating a “us” and “them” atmosphere a very good reminder that this is really about pulling teams together to work better. Thanks for the reminders to not become part of the problem.
NX
The final “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” is the key. I really like the way Dale Emery recasts the issue–when someone seems to be resisting a change, look for what it is that they value and they’re trying to preserve. When I do this, I find there are a lot more than four types of resistors. Instead, each is unique. Once I recognize this, I can start to do something to help.
Thanks, Nick. If an us/them culture results, the transition will have real trouble.
Hi George-
Yes, that last part is the key. We’re not going to “fix people” and resistance should be taken as an insight into what the person is thinking. I know some people hate seeing a matrix grouping people and say “oh but everyone is unique.” Of course, that’s true but sometimes the groups can be helpful. I think in the chapter in Succeeding with Agile I stress that each person is to be considered individually but knowing “ah, this guy seems to be resisting for this general set of reasons” can be helpful if we know a few good techniques for that type of resistance. That’s what I’ve tried to present.
“Passive resistance occurs when someone fails to take a specific action, usually after saying he will.”
This is incongruent behavior, as Jerry Weinberg points out in QSM Vol. 3. Here I would remind myself to dig deeper at it. Why is the individual incongruent. What causes might he have to do so? If it’s a lack of common mental model, I need to work on the mental modelling as a coach. Also the cultural background here might matter. I made some experiences with incongruent behavior in certain cultural backgrounds, while they are absent in others.
Overall great write-up, and as long as you keep updating me on your book, it jumps up on my “to-be-read” list of books on my shelf. “Too much to read, too less time.”
Great post Mike. I like the quote at the end especially. We need to listen to why leaders don’t want to adopt Scrum, and work to solve those problems. Perhaps they have misconceptions of what Scrum means, or they think progress will be derailed due to a “big bang” conversion. Whatever it is, there is a root cause. If we can seek out and alleviate the root cause, we have a much greater chance of success.
Hi Markus–
Thanks for your comments and your reminders about Weinberg’s QSM books. I read each when it first came out and enjoyed them. I’ve had a desire to revisit them so they are moving to the top of my re-read list.
Hi Robert–
Good point about listening to leaders as to why they don’t want to adopt Scrum. Normally when I’m listening to someone and trying to understand their hesitation (about anything) I try to find what outcome they are fearful of. An executive may be fearful of losing predictability if they go to Scrum (as one of many examples). Since this doesn’t have to be the case, I’ll work to remove that fear. Many times the root causes originated in some past project that went awry.
Our company is still in the transition into implementing Scrum in the development department. Overall, the company is also looking to implement ITIL.
Last week, the ITIL point person attended some of the Daily Scrums to observe, and afterwards asked the teams the question, “So, how is Scrum working out for you?” Generally the attitude is positive, but there are also comments like “I prefer the waterfall, I like to know what I’ll be doing in the future, not just one sprint at the time. With waterfall I am in more control of my situation, and can deliver better code.” The reasoning seems to be “it didn’t really succeed with waterfall, but at least we knew what we were supposed to be doing every day for the next year. Now, we only know what we will be doing for the next sprint and there’s no saying we’ll succeed this time either” – fairly disillusioned wouldn’t you say?
(I am still surprised that developers today prefer waterfall to iterative development – I would have an easier time if someone said they preferred RUP to Scrum, at least RUP is iterative and can be agile! But I digress.)
This “I like the predictability of waterfall”-attitude I would put somewhere between the Followers and the Skeptics box, or a mix of those two. There is no active resistance, and only when asked does the argument come forth, but there is a dislike of Scrum and Agile. Generally, people with this attitude do the Scrum activities as they should (because they’re told), but not with enthusiasm.
We’re into our third (2-week) sprint now, and will do one more before the holidays, and have planned a major retrospective with the new year. Getting to the root cause of the disillusioned attitude is the key to succeed. I intend to lean heavily on Esther Darby and Diana Larsen’s book “Agile Retrospectives” for this, but would also welcome suggestions on other publications for this?
–
(BTW, I really like the Borg reference – given my SF interest and my last name
Adne,
Esther & Diana’s book is a great source of information! I’d also recommend anything from Jean Tabaka, such as Collaboration Explained. If you Google her you’ll find online videos on YouTube to assist with Retrospectives.
I haven’t read your book or the rest of this site, just this entry so sorry if this has already been covered.
What leaps out at me is that there are people that dislike uncertainty in any form and are quite happy to indulge in what I call “False Certainty” i.e. the illusion that things are certain when all the evidence is that it is not. “I like the predictability of waterfall” is a classic example of “false certainty” the predictable things about waterfall are that they will be over budget or late or not actually meet the requiremnts of the business today (as opposed to 6-9 months ago when the spec was agreed)
This is as much a personality type issue than directly to do with adopting agile. If you are familiar with Myers-Briggs, I am referring to J types liking certainty and order rather than P types who prefer spontanaity and change.
When I have been successful in getting agile adopted it has been when “false certainty” is recognised and regularly addressed and the people involved recognise that it may not be their personality type preference. It helps if the leaders and opinion formers around the project are P types or at least recognise that the “the change programme has to be able to change”
Jeremy Renwick
Agile Project Leader, DSDM Practitioner
Hi Jeemy–
Good points. A similar case is when people compare a real agile project (warts and all) to a hypothetical waterfall project. At a theoretical level nothing beats a waterfall project–if we could perfectly do analysis then perfectly do design then code perfectly etc. that would be the shortest the project could be. Agile (or anything) will always fall short when compared to that fantasy.
In the world of debate, always contrasting Waterfall and Scrum(or “agile” which denotes no process in particular) is called a strawman – choosing your opposing case, whether it is real or not, to solidify your own position. I have been in software development 20 years (Over a dozen companies – most being command performances), and I have yet to see true waterfall. I also have yet to see true Scrum. What I have seen are good and bad process, good and bad practitioners, and a lot of people telling others how to act. Lately I have seen a lot of religion and saluting. Iterative development has been around a very long time – most of the tools pitched by agile pundits are not new inventions; The big difference I see is an overwelming dedication to staying myopic and anti-anything that does not salute the manifesto. I have seen four-hour CMMI level 3 cycle time, birth to live data center production deployment; I have seen 500 man-year projects reduced to 2 man-years, using methods nowhere in the agile doctrine. And to suggest that you can sustainably delivery quality functionality at speed using anything else has the pundits insulting your heritage and screaming the dogma louder. I believe in the tools found across the agile world – I don’t believe I should have to talk Agile versus Fragile, YAGNI, and so on. I have a big problem with the religion of agile; And I have a problem with those who choose not to see. Perhaps some resistors actually have found something worth looking at – will Scrum allow for that? If it won’t – it is religion; It is yet another form of process naziism. Any frenzy, mob, or groupthink needs to exposed for what it is – Professionalism means staying objective. I also have a little problem with weak understanding of human Pschology; More Weinberg please. ITIL – not really a process – but a reference library of practices – sort of; You can do bad ITIL just like you can do bad Scrum. Which takes where I was going – quit trying to implement Scrum and do what works; If the methods of Scrum get you there – great… Perhape some of the “resistors” just don’t like religion.
Jeff-
If you’ll take a look through the Succeeding with Agile book you will see that I am hardly a religious zealot unwilling to consider other viewpoints. In fact, I struggled a long time with even putting “Scrum” in the subtitle of the book because for years I have been making the point that I am in favor of “unbranded agile.”
I’m also on record as saying I want agile to go away. In the same sense that no one says “I need to go to the object-oriented design meeting at 9am” (they just call it a “design meeting”) I’m anxious for the time when we can stop talking about agile entirely. For more on that see the interview of me in Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders by Andrew Stellman and Jennifer Greene.
Perfect
I tend to be a voracious reader – but missed these so far. Maybe I add them to my Christmas list. Also, thanks for the clarification on your position… I hope we can be successful along these lines.
Raising the industry capability, helping people drive great quality and product… Getting all that branding out of the way would definitely help.
Jeff
@Jeemy Ranwick,
It could well be that the team members that like waterfall for its predictability just don’t get confronted with the negative çonsequences of waterfall. They are quite comfortable in their role, doing their job delivering software according to the specifications. In many waterfall companies team members will never know whether or not the end-result meets the client’s business goals and probably won’t care. They’re happily locked in their (developer?) role.
This attitude is very much a personality and cultural thing and the team members are definitely in the follower quadrant in the article above.
-erik