So, you introduced agile concepts to your team, brought in an agile coach, and tried to coax and cajole the team into accepting the new process. But there’s still lingering resistance to the new way of working, and team members are nominally complying without really buying into the new approach.

Sound familiar?

Many engineering leaders and agile coaches believe that transitioning to an agile approach is simply a matter of training and, perhaps, expert advice. The spirit of team empowerment inherent in agile (compared to waterfall) should be enough to win everyone over—or so the thinking goes.

Many leaders don’t realize that moving to agile is really an organizational change initiative, not simply a matter of proper process adoption. Any organizational change initiative must address the following realities:

• There are winners and losers. The change in work process or reporting relationships means that, relative to the status quo, some people will be granted power or control at the expense of others. Those who stand to lose will be among the first to resist.
• Like people, organizations form habits that are hard to break. The way that teams make decisions, run meetings, or collaborate becomes reinforced over time and eventually becomes automatic. Enacting new team behaviors often presents ambiguity (around how to do it properly), introduces risk (around who is accountable for it), and requires energy (both at an individual level and for the extra facilitation required to make it stick). In contrast, the old way often appears safe, comfortable, and easy.

For example, at one of my prior companies where we attempted to adopt Scrum, the product managers perceived a loss of control in shifting to agile. In our existing waterfall process, they were responsible for a significant amount of design work by building UI mockups when creating specs. With Scrum, design was going to become a team activity, so the engineers stood to gain on that front. (As it turns out, the product team stood to gain in other ways—but more on that later.)

Even after we adopted Scrum, the team would still defer to the product manager for all UI design work done during sprint planning meetings. While all engineers contributed, once a product manager chimed in, discussion ended. This wasn’t due to a poor understanding of roles and responsibilities, or to a lack of agile coaching—we had an experienced and very capable agile coach guiding us—but simply because of habit. It took conscious, sustained effort to get the engineers to feel empowered enough to demonstrate a sense of ownership over UI design.

Given these characteristics of organizational change, what can you do today to overcome your team’s resistance to agile? Here are eight steps to get you on the right path.

1. Explain the need for change. Take a step back and help the team to understand why a change in process in necessary. What benefits are you hoping to realize, and why are they desperately needed? Help the team experience firsthand the pain that the current process is creating.

For example, let’s say you want to be more responsive to customer support issues. Have your team sit in on a few support calls. Trying to shore up a competitive weakness? Have your team attend a sales call in a competitive deal. Trying to respond more swiftly to customer requests? Have your team attend an account management call with an unhappy customer who has many longstanding requests awaiting action.

2. Actively listen and incorporate process feedback. When you hear pushback from your team, meet one on one with the members and use the following active listening techniques to help them feel heard: suspend judgment of the speaker, reflect back what you hear to ensure you understand correctly, acknowledge their emotions, and follow (don’t lead) the conversation. Let go of any desire for process purity and incorporate their feedback into process changes.

Active listening sounds easier to do than it is. We routinely judge what we hear—and, in fact, our brains are wired to do so. Giving each person’s concerns an explicit airing and demonstrating how their input is being applied will go a long way toward addressing their angst.

3. Frame the benefits to all parties. Analyze who the winners and losers are relative to the status quo for each issue, and pitch each loser on how they benefit in a tangible way on what they ultimately care about.

For example, at my previous company, product managers did indeed stand to lose a measure of control over UI design by adopting Scrum. However, Scrum would also provide them greater visibility into work in process and greater responsiveness to business needs. The visibility and responsiveness would help them look better in front of sales and customers, which they viewed as a huge win, particularly when fielding tough questions about when a feature would be available.

4. Use key influencers. Assess who the holdouts are and identify whom they defer to, look up to, or seek advice from on technical issues. Ask these people to pitch them on the benefits of the new approach and how their help and support is crucial.

If you’re unsure where influence flows amongst your team, sit back and carefully observe interactions at your next team meeting. When a significant unanswered question or ambiguous issue is presented, to whom do people’s eyes turn? Whose comments seem to carry the most weight in creating clarity or direction on the issue? Where do affinities appear to lie?

5. Measure outcomes and promote successes. Begin regularly measuring the outcomes you are hoping to achieve, if you’re not already. Your measures should relate back to the original need for change and show how you’re making progress on the organizational pain points that required action. Highlight movements in the right direction, show why these matter, and include direct quotes from the impacted people for maximum effect. If your goal was to improve responsiveness to customer support issues or feature requests, measure and highlight improvements in customer satisfaction. If competitive advantage was the goal, highlight an increase in competitive deals won.

6. Use social pressure. We’re wired to respond to social pressure, or to how the pack performs. You can leverage this powerful influence by providing visibility into performance and using recognition to praise achievement.

For example, if you have multiple teams, consider measuring and regularly rewarding the team with the greatest improvement in desired behavior, such as largest velocity or least number of bugs found. The key is to create a prominent dashboard displaying every team’s performance so everyone can get instant feedback. The recognition and reward will act as subtle pressure, pushing people on each team to rally each other.

7. Monitor and attend to naysayers. We’ve all had an experience with a team member who just couldn’t be placated—despite providing context, listening to concerns, incorporating feedback, and creating incentives. Keep a close watch on these team members, continue to engage them, and help them feel heard. Record and share your observations about their behavior, your attempts to involve them, and the effect they are having on others.

8. Isolate stubborn detractors from change. If all else fails and you have a stubborn detractor, you run the risk that he or she may quietly poison the climate, undermine your progress, and instill doubt in others’ minds about whether agile can be a success. Once you see they are having a persistent and negative effect on other team members, it’s time to take action and shift them into a new or different position to isolate them from agile. Once they see results and become convinced of agile’s success, they can always be brought back into the fold.

In fourteen years of leading engineering and product teams—and failed agile attempts at three companies despite excellent training and advising—I've learned firsthand how successful organizational change needs much more than simply process training and advising. It requires deploying your influencing skills in often subtle ways to get real buy-in, address resistance, and keep team members motivated. The upside, though, is successfully realizing all the promised benefits of agile and creating happier, more productive teams.