One thing has always concerned me about the tremendous volume of material about change—books, articles, presentations—and that is an underlying assumption that the change (or preferably the adaptation to the change) in question is a good one. With that as an assumption, then the “problem” is how to align everyone with the adaptation. One of the best models for managing change is the Satir curve (Figure 1.0). The model takes us from status quo, through a change initiation that is resisted, causes some chaos as people learn, and finally ends up being integrated into the new status quo, hopefully at a higher performance level. At any point in the process, the “anti-change” forces may prevail and the adaptation process fails.
This model, and many others, seem to ignore the question, “Is this a good adaptation?” The entire process is geared to overcoming resistance, and resistance always has a negative connotation. But think about change a minute. Environmental changes create both opportunity and danger. In any business, development organization, or project team there are many, many changes: market, economic, competitor, team member, business objectives, and so on. For any one of those changes there may be multiple possible adaptations. With hundreds of changes, large and small, and hundreds of possible adaptations to each, again both large and small—how do we weed out the adaptations that are wrong choices?
Maybe we should look at the Satir model, and others, not from the negative perspective of overcoming resistance, but from a positive perspective of helping us weed out the inappropriate adaptations while helping us implement the appropriate ones. Rather than a failure, opting out of an adaptation at some point along the curve many be the best thing that could happen! In talking with colleague Josh Kerievsky about this topic, he recounted the time he tried to change to an ergonomic keyboard, in the middle of writing his Refactoring to Patterns book. Good change, bad timing. He opted out of this particular change.
Which brings us to resistance—and doubt. For a long time I thought about resistance as a negative thing, but then also allowed as how some resistance was useful. I finally came to the conclusion that we need another word, and the word I picked was doubt. Resistance is defined as opposing something you disagree with. We often link resistance with fear—fear of losing a job, or influence. Doubt has a different connotation, it is uncertainty about the truth.
Differentiating between resistance and doubt leads to a couple of outcomes. First, we should approach any adaptation process, even implementing an agile methodology, with a certain amount of doubt and skepticism—it is very healthy. Just like cancelling a project when new information indicates the benefits no longer outweigh the costs, opting out of an adaptation when new information indicates the change won’t meet the objectives is a positive, not a negative outcome. Second, resistance and doubt need to be handled in different ways. Resistance is fundamentally emotional and new information doesn’t tend to overcome it, especially resistance engendered by fear. Some agilists come in and declare, “we won’t need project managers anymore,” and then wonder why the agile implementation is met with resistance.
Doubters are asking for additional information. When we confuse doubt and resistance we tend to mismanage the adaptation process. When we act out of a feeling, “they are just being resistant to the change,” we may fail to respond appropriately. Doubters aren’t being obstructionist, they are asking for information to allay their concerns.
Changes, or adaptations occur at a team level as well. For example, an agile team is expected to create shippable features every sprint. If that isn’t happening the team needs to investigate what adaptations might help achieve that goal—for example, more automated testing. There may be doubt about whether the adaptation will work (our application is different). There may be resistance to task assignments (developers taking time to implement test harnesses). As the team goes through a “mini” Satir change process they will need to re-evaluate the success of the adaptation at the end of sprints. The team will need to gather more information about how to increase automated testing in their environment, and they will need to assure developers that the time spent on developing test harnesses will be taken into account in sprint planning.
All of this means that the whole change-adaptation process is more difficult than we would like for it to be. It means that a degree of doubt, skepticism, and even resistance can be very positive when it keeps us from making a mistake in how we respond to change. It comes back to one of the key attributes of the agile manager—being able to balance, rather than being prescriptive.