Inverting Agile Resistance

  • Posted on: 7 April 2023
  • By: David Hersey
Printer-friendly version
Resistor on an electrical board

As an Agile Coach one of the biggest frustrations for me is when people either won't try something I'm suggesting, or they try it but don't seem to be able to get the point of it, or actively try to sabotage it.


How many times have I heard, “Well, we tried that and it didn't work.” I have a whole WhatsApp channel full of other coaches mostly complaining about their clients.  Either the teams or the management simply are not listening or trying hard enough to make these otherwise sensible, enlightened, helpful suggestions work for them, so that they too can experience how easy and fun it is to work in an Agile team!


Maybe you’ve had similar experiences?  Or maybe you are one of the people struggling to make Agile work for you in your team?  Possibly you, yourself have been labeled… <gasp> … an Agile resistor(!?)


This blog post is not about another Agilist whining about Agile resistance. Because I no longer believe that Agile resistance exists.


I decided to give this some thought after many years of banging my head, because confronting it head on wasn't making any headway. I can be a pretty forceful coach sometimes. But browbeating people into trying something that made sense to me has never led to the Agile results I was after.  I asked myself, why do I think that is?  Are these people just stupid? Or stubborn? Maybe they are egotistical, “in the know” and unable to hear new ideas? Or maybe they just don't like me?


What I discovered, by listening and understanding vs teaching and preaching, is that whenever I was perceiving something that looked like resistance, it was due to me not fully understanding the good people I was working with, how their career experience differed from mine, and how they had adapted to the less-than-ideal way of working corporate projects before Agile became accepted.


I started to think about what goes on in the head of somebody like that, who's been working for a number of years successfully in a role in a non agile organization, and how their experiences have differed from mine.


As one of the early Agilists, I never experienced resistance to change.  Rather I was actively pushing the envelope to get more Agile (we did not call it that until years later).  Like everyone at that time, I was stuck working in an environment consisting of unrealistic project plans, where product planning was given short shrift to allow more time to write code, or where years of analysis were invested pin shelf-feet of documentation for projects that were ultimately scrapped because even the basic assumptions were untested. 


Every day I could see the waste in long drawn out meetings that led to little information exchange and no decisions. Frankly, I was tired of staying in the office till 10 or 11 o'clock at night to try to mitigate the impact of doomed plans created by others without knowledge of what was involved in doing the work. 


So when I saw an opportunity to throw a lot of that stuff out and start working on increments of tested, potentially shippable software, adjusting scope, time or effort (but not all 3!) to maximize impact, having conversations with the customer in the room, throwing away the up-front estimate in favor of relative size and working at a sustainable pace, I was all in!  


This does not make me smarter, it just reflects how I handled being in a dysfunctional environment.  I was willing to risk breaking some rules to find better ways of working because the alternative, for me, was unacceptable.  I was willing to fail in my career rather than live within a broken system that mainly produced pain and waste.


Others, perhaps more adaptable than me, responded to the same dysfunctional system by learning to make it work for them.  They are the people that I was coaching 10 and 20 years later, people who have been in careers in their organization as a developer or manager or leader and had become very successful making a system that they're familiar with work for them.  And that’s more than I was able to do. Through perseverance and adaptation, through developing principles that could make a broken system work, and by definition, quite successfully!  How do I know? They and their successors are still here. 


The aha moment from me came when I realized that those who are currently teaching Agile fall more into the “I want to fix this broken system” group, and those who are learning Agile fall more into the “I will make this system work for me” group.  And the way each group sees Agile is very different.  And when I fail to appreciate that difference, I fail to coach and that is when I faced what I perceived as Agile resistance.  Resistance therefore is not a sign of stubbornness or stupidity, rather is it a sign that I lack empathy. 


Imagine that you have been successfully working in a non-Agile organization for years, getting rewarded for your hard work and shielded from blame when things go awry.  You may not be ecstatic about how things work, but you are OK with it and sometimes things go very well.  One day, you are confronted with an edict from management saying, “we're going to change everything, now listen to this new upstart guy from the outside and he will tell you what to do differently”.  Maybe you’ve heard about Agile, and maybe some of the things were even good.  Maybe you’re actively hostile to the change because you see it as threatening. 

This new person comes in and says "hey, you know, there's some stuff that you folks are doing that just doesn't work, like estimating, and planning in detail more than a few weeks out.  Like designing software before we write the code.  Like working alone in your cubicle all day.  I suggest we stop doing those things. And what I'd like to do instead is start shipping bug free software every two weeks. I'd like you to work side by side very transparently with other engineers. I'd like you to, in fact, pair with them and show them your thought process as you're crafting your code. Let them see all the things that you do or don't know. Expose your innermost engineering secrets in the full light of day. And then by the way, we'll all walk through our code with everybody else on the team. So everybody gets to see the product of your thinking. Won't that be fun?"


Holy tripwire Batman! I can't believe I ever got anybody to even remotely try something like that. It cuts across every margin of safety that people around me had ever had!  For years, it has been the underpinning of their successful career to not do these things!


Considering all of this, I began to develop a new respect for the courageous few that had actually trusted me long enough to try these things and see that they worked better for them, and empathy for those who either looked away, or actively challenged these ideas. 


Rather than seeing resistance as a problem, I saw it as a signal that I was not connected to the people I was coaching.  I inverted the resistance, and I focused my attention on finding ways to put myself in the shoes of the people whose careers and sense of safety I was blundering around with.  It became an opportunity to ask questions, to share stories, to ask if people saw the same problems I did with the old ways of working.  To respectfully ask individuals and teams to help me try an experiment; one which only has to be kept if it works better after a heartfelt effort. 


And, it worked. My frustration level went way down, and my effectiveness went way up. It was no longer about my ideas vs theirs … Agile became a shared opportunity to find better ways of working, together.