Agile coach Morgan Ahlström recently turned to the Agile Coach Support mailing list to ask how to deal with an organization that said they wanted the benefits of becoming more agile, but was behaving in ways contrary to that goal.
Here's how he described his situation,
You're brought in as an agile coach but what you do is not really agile coaching. Do you walk away from the mission? Do you work hard to make them agile since this is what they're paying you to do even though they really don't want to change? Do you play their game while trying to do some good? Do you change your title to something else while trying to help them out? What other courses of action have you found that have worked for you?
D. André Dhondt gave his thoughts,
In my opinion, improvement and agile are two separate things. I'd focus on where they want to improve / what their pain points are, and forget 'Agile'. I'd still work on communication, people and interactions, but would forget the Agile lingo.
Peter Green followed up with,
We all wish we could change the world with every coaching opportunity. And often we can get caught in the trap that if they don't "go all the way" with agile, then we haven't done our job. However, we need to take a kaizen approach - a little improvement, day after day, really adds up.There are lots of small, subtle changes we can help teams and organizations make that move us and them toward the agile values. It is frustrating when it is slow, but slow change is still change.
Tim Ottinger brought some historical insight to the discussion as well as a warning,
My ongoing meme here: "Seeming" is the enemy of "becoming."When XP and Scrum started, they weren't the goal or the reason for doing things in a given way. They touched on something deeper about how people work together, and came from experiments in doing software really well. That's because it seemed nuts. XP was the way to reach deeper and achieve more/better/sooner/safer/cleaner and people adopted it. We stand dangerously close to "Agile" now becoming the barrier rather than the conduit. People will comply with the rules rather than using them to connect.
Later he added,
I've been in the situation where developers and their managers were just biding their time and waiting for me to leave and the whole "agile" thing to blow over. It was awful.OTOH, if you can touch only a few lives, you've done something. If you are able to reach past practices to people then you can make a difference, and maybe you'll light a few wicks. Don't confuse frustration with failure, b/c they're not the same.
Here was Lior Friedman's take,
People often fall back to their old habits especially when pressure starts to rise. It’s not really important what we call the process, as long as I manage to keep things 100% visible making sure everyone understands where we are and how things are going. I myself am happy with every improvement I succeed in helping.If I honestly think that the ROI of me being there is positive, I’ll continue in trying helping them and make the best I can in the given context.
George Dinwiddie echoed the pragmatic sentiment,
Even though much of my work is coaching transitions to Agile, my goal is not "reaching agile" but helping people develop software & other systems more effectively."Helping" means that they are getting benefits that they want, not that I want. If I'm not helping, it's time for me to leave. There can be other reasons to leave, also.
Tim Ottinger rounded out the conversation with a link to a piece he and Jeff Langr had written, titled What Agile is Not"