That's what Michael Feathers said to me at Agile 2009. It was the end of Patrick Wilson-Welsh's Ugly Code vs Clean Code clinic, and I had gathered a group of people to see if they could help me solve my problem: an organization with a *huge* legacy application (2.5 million lines of *true* legacy code -- no unit testing, no automation, eek!), stuck in a time long since past, where the development team is surrounded by a closely guarded fortress, and the test team was really just there to have someone to blame when customers complained.
After he asked me a series of questions (which really just confirmed that I had already been trying all the things that an expert would have suggested), he said something that stopped most of the group dead in their tracks for a split second: "Change your organization or change your organization". It was a phrase I had heard before, yet at that moment, it hit me like a ton of bricks.
There are countless resources out there for supporting those people who are "change agents", who help spark change where they work, who have gone through or are going through Agile transitions. There are resources for those who are dealing with the more difficult aspects, such as people who just resist change. Markus Gartner wrote up a great summary recently on his blog.
There are many techniques for pushing through resistance, but how can you tell a fight that isn't winnable? Or, at least, isn't winnable for you?
It seems to be something you just "know", from what I can glean. And it is certainly not specific to organizational change. Kenny Rogers sang that wildly popular song The Gambler, "You gotta know when to hold 'em, know when to fold 'em, know when to walk away, know when to run..." The question I have always wondered is "*HOW* do you know?"
I suppose it's not an answerable question at face value. Each situation is different, filled with countless variables, and there is not a single, universal answer.
What is the dark side of what happens to a change agent who is outnumbered, lacking in authority, and just shut down at every turn? Markus's term, "cultural infection" was what happened to me. The crazy culture that I inserted myself into became too much for me to bear, and infected my personal and family life. That was when I knew it was time to fold 'em.
The thing that has gnawed away at me for all of my (relatively short) time as an Agile champion, is "What happens to the people who just don't do well working this way?" or "What happens to the people who don't *want* to change?"
Sometimes, they are pushed out by those who do want to change. I've seen that, people who become so miserable because their interest in working in silos makes them the odd man out, and they eventually get so miserable that they leave.
But what happens when there are more people who prefer to work that way than people who want to change? Or worse (in my view), there may be more (in the organization) who *want* change than those who don't, but the group that doesn't want to change is concentrated in the people who develop the production code?
If an entire team of developers does *not* want to change to a more collaborative environment, or better, to Agile, how can any other department succeed, even if they *do* want to work in a more collaborative way? Can you incent people to change if they don't want to, or have no reason to change?
Believe me, I've tried. I've followed the patterns in Fearless Change, made the countless arguments *for* Agile available on the web, posted slides from various talks on my cubicle, talked to people until I was blue in the face, decided to run *just* my QA department in this fashion, asked the "just try it for a short time" questions, run some small tools on my own that would help the current development dilemma, show graphs and line charts and cost analysis studies, put together presentations. Still, I am forced to sit and wait until a release "in a pretty package" (yes, that has actually been said to me) is ready for my test team to have at it. Still, I get that pretty package, and can't do anything with it because the software doesn't install properly.
I've learned that there are organizations where even though the old-skool Waterfall style of doing things has so clearly gotten them into trouble, they don't see that. Worse, the developers continue to be held up on a pedestal, regardless of those signs. When this happens, the culture of the *whole organization* has obviously supported it, and possibly is continuing to support staying *just the way they are*.
I am reminded of a Jerry Weinberg quote: "Things are the way they are because they got that way".
I'd be willing to bet that even when an organization is this deeply rooted in their ways in the face of adversity, some can still embrace change and come out of it far better than they have ever been. I don't know how to tell the difference between those that can and those that are bound to continue repeating the same mistakes.
I've talked before about the "wall of pain". If an organization never lets those responsible feel the "wall of pain", they will rarely have any reason to change. For me, I've hit my personal "wall of pain" before the organization hit theirs.