2 . The Myth of Resistance to Change
This is a story about a time I failed, and then learned the most important lesson of my career
SUMMARY
One of the most important skills an Agilist must have is that of the Change Agent. Continuous improvement is fundamentally all about change, and we’re expected to find clever ways of convincing people to do things differently. That process is not just a curve, but more like a convoluted path, with forward and backward movement in multiple places, and a lot of frustration and resentment and anxiety all throughout the journey. We’re called upon to help people get through all that, and if you’re anything like me, that’s both the toughest and the most rewarding part of your work.
By Julie Bright
Once upon a time, not so very long ago, I was a fairly new Scrum Master. I had been serving in that role long enough to know a thing or two, but was inexperienced enough that when I was asked to start up a brand new, pretty complex team, I was incredibly proud to be entrusted with the task.
This new team was to be composed of employees from two different parts of the company, as well as contractors both onsite in the US and in India. The team was working to move some legacy processes into the cloud, switching to a microservice architecture. No one on the team had ever done this before, so everything was new.
The internal employees had various, mostly negative experiences with Agile, and the contractors had virtually none. The direct employees had been business analysts, but when the company changed to Agile delivery methods, that role was eliminated, and their job titles changed to Software Engineers. Though they had a deep technical understanding of the business intent and the logic of the existing systems, they were unfamiliar with cloud technology and didn’t write much code. The contractors were Java developers with no experience in the company. What a challenge! I was thrilled to be the one who could teach them to be a high performing team.
I scheduled the necessary meetings: Standup, Backlog Refinement, Sprint Planning, Retrospective. I explained the reason for each of these, and sent emails with links to additional information so they could continue their learning journey.
While I was teaching them about these Agile practices, I was also learning. I’d never had a distributed team before, and I spent many hours pouring over books and web pages to find new and interesting techniques for keeping people engaged while not in the same room. I experimented with online tools for retrospectives, and put into place practices designed to get everyone talking and build team spirit.
For all my enthusiasm, however, it wasn’t going as well as I had hoped. They struggled with the idea of thin vertical slices of value. They pushed back on the story writing techniques I shared with them, saying it wouldn’t work in this case, because Reasons. I was starting to feel frustrated at the resistance I was encountering. Some of them expressed irritation at having to do retrospectives when there was so much Important Work to be done. The contractors kept their heads down and their mouths closed.
One day, I was facilitating a retrospective that went so badly I felt I was facing down an angry mob. I couldn’t understand what they hated so much about this thing I loved. With the tension in the room thick as peanut butter, I found myself standing in front of them, dry erase marker in my hand, imagining my feet growing roots down into the ground so I wouldn’t be physically bowled over by the force of their resentment. In that moment, I gave up and told them that even if they didn’t like Agile, it was here to stay; the company had told us this is how we have to do things from now on.
Defeated and angry, but also feeling like I’d failed, I turned to one of the external Agile Coaches the company had hired to help us in our Transformation. In tears, I told him of my struggle and how stubborn and difficult these people were. He recommended that I let them change something about their practices. Skeptical, I worried that they would throw Agile out the window and my manager would see that I had failed. My coach friend suggested that I have them write their own acceptance criteria for how their change will meet the intent of the original practice. This seemed like wisdom, but I wasn’t sold, and needed more time to consider his advice.
A couple days later, with this idea marinating in the back of my mind, I went to my first Agile Coach Camp. I was enthralled by the Open Space facilitation format and participated hungrily in the sessions, soaking up as much knowledge as I could. I learned that the power of Open Space was in the Invitation, in the trust that the attendees know where they can best teach and learn. During the lunch break on the first day, I chatted eagerly with an experienced Coach I’d met that day. He asked me about my role, and I told him all about the difficult team I was trying to help. “Why are these people so resistant to change?” I complained.
His eyes twinkled. “People are not resistant to change. That’s a myth.” I laughed out loud. He followed up immediately with these words:
“They’re resistant to BEING CHANGED. They’re resistant to COERCION.”
I’ll never know for sure, but I imagine my jaw hitting my lap. The past few hours had been so powerful for me because I was learning about the importance of Invitation over Imposition. It seemed so obvious in hindsight. I had been IMPOSING Agile, instead of trusting the people to use their big brains to solve the problems in front of them. I thought I knew what they needed, what was best for them.
I was an Agile Evangelist, and it was deeply offensive.
I’d been imposing my Agile religion upon them, because I believed in my heart that it would make them happier, more productive, and proud. But I didn’t TRUST them. How could they trust me?
From the conference, I logged into my work computer and put a meeting on my teams’ calendars for my first day back at work, entitled, “OPTIONAL: How Julie Screwed Up, And Why She’s So Excited About It.”
They all came.
I apologized to the whole team. I told them I hadn’t understood their position, that I had believed it was my JOB to teach them how to Do Agile, but what I should have been doing was helping them to discover how agility looked on them, a little at a time, with them at the wheel, learning along the way.
This humility and honesty was well received by the team. I asked them what they hated about Agile the most. The Backlog Refinement meeting was at the top of the list. They said it was frustrating that they spent the entire hour working on just one user story, because the Java developers had no context, so when Sprint Planning came around, they weren’t prepared. It felt wasteful. I acknowledged this, and asked what they’d rather do instead.
“Well, really, we’re business analysts, not software developers. What we are really good at isn’t valued anymore, but we think it would be better to do some backlog refinement upstream of the bigger meeting, with just a few of us who already understand the business, and then bring it to the developers for a solution in code.” I agreed that this sounded perfectly reasonable and that they should feel free to start doing that right away.
The mood of the team changed immediately. I was letting the people do their thing in their way, with the understanding of the intent behind the practices, and the empowerment created by self-organization and trust. And although I had feared that, given the chance, they’d discard Agile entirely, their solution to crappy refinement was to do MORE REFINEMENT, but on their own terms.
One of my greatest failures was also my most powerful learning. When you show people the intended destination, and invite them to co-create the journey, they are far less likely to push back in resentment, and instead will come up with creative solutions which meet the goals in unexpected, wonderful, empowered ways.
I am Julie Bright and these are my agile-thoughts
2021 © Charlottesville, Virginia, USA by Julie Bright
Julie Bright has transformed herself multiple times in her life. After getting her degree in Psychology, she worked in procurement, served as a childbirth doula, supported government engineers designing military safety equipment, and even tried her hand at self-employment as a personal chef.
Her career in IT began over 10 years ago when she became a project manager, but when she discovered Agile she found her true calling.
Passionate about any process which fosters healthy group dynamics, Julie is happiest when facilitating workshops, teaching Agile concepts through games, and co-creating professional environments where people can feel motivated, engaged, and empowered. Tickled to finally put her Psychology degree to good use, she is most interested in Social Psychology, particularly as it applies to Organizational Culture and Change.