Agile adoptions stall for a number of reasons. On the surface, it may seem that there is a cultural mismatch, that people don’t like change, or that people just don’t have time available. Although those things must be addressed for change to take root, I have found that it’s often the process for getting people to change that’s broken.
There are a number of models available for managing change. Prosci’s ADKAR and John Kotter’s 8-Step Change Model are two of the most popular, and there are a lot of great ideas in both of those models. However, they both miss a key element needed for successful change:
Feedback.
Traditional change management is like traditional project management – there is a focus on establishing “the perfect plan” at the beginning. Changing how a group of people thinks and behaves will always be a complex problem. You can’t predict all of the ways that people will misunderstand, misapply, ignore, or undermine the change until you begin. When working through complex changes like this, you need to set up a safe environment for people to experiment, get quick feedback, and discover what is and isn’t working. You can learn more about this in HBR’s A Leader’s Framework for Decision Making.
Change efforts like Agile adoptions will not succeed unless you frequently get raw, honest feedback about how your changes are being perceived. In a nutshell, you can’t expect your teams to be agile if you can’t be agile yourself with how you execute changes. You need agile change management. It’s important to constantly ask questions like:
- What do you think is causing us to make these changes?
- What excites you about the changes being made?
- What worries you about the changes being made?
- What successes have you seen from the changes?
- How do these changes help or hurt your ability to get work done?
- What skills or resources do you need to keep making progress?
So although it may seem that your people just don’t like Scrum or that they are just generally resistant to change, maybe they don’t know why the change is necessary, or maybe they haven’t bought into the reason for the change, or maybe they don’t think it will benefit them, or maybe they just don’t have the time available. You won’t know until you ask.
I used this blog post as a reference in a training I gave today. I think it is an important lesson, as people nod their heads along in agreement with the topic of empirical process control, while simultaneously wanting some rigid, prescribed, out of the box “agile process.” Good job, Jordan.
Thanks, Chris!