Sunday, November 15, 2009

Change your organization, or change your organization

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.


Marlena Compton said...

This post is like the story of my job...I work in an area that has cobbled together something new from many pieces of old. I've pushed so hard for unit testing with technology that is not readily unit tested, manipulated my dev into helping me unit test and nearly given up. This past Friday, I noticed the green command line display of Googletest on said dev's monitor as I was passing. It appears that by backing away, I gave him the space to "process" the value of unit testing and pick it up on his own. Maybe this is an outlier, but perhaps sometimes it takes planting the seed and backing away.

Dawn said...

Hi Marlena, thanks for reading! :) I have a lot of respect for you and appreciate your feedback.

I expected much the same thing to happen early in my time with this organization. I offered tools to help, often times offering privately so that people could present the ideas as their own. I can think of at least a dozen examples where I was either completely ignored or told to stay out of their business. It took me 3 months to even get a hold of the source code for the product - source code that does not build without a super-secret dev-only 12-step process, so all I could do was look at it.

I hope that others leave comments with such practical advice; I've gotten many in the past several months and tried each and every one.

Admittedly, maybe I haven't tried hard enough, but my family simply mus come first.

RN said...

Thanks for sharing.

Disclaimer first: I am a developer but have worked very closely with Testers , even led a very energetic team of testers at times.

Maybe you need to analyze their pain points and find the overlap between their troubles and yours. That will give you a starting point... and this is your retrospective in stealth mode...

For organizations resistant to change- perhaps stealth mode is the best way to go

Good luck !!!

George Dinwiddie said...

Dawn, you can't change an organization. Change happens one person at a time. That is, of course, very slow if the organization is large and you're the only change agent. It also says that you have to give a lot of consideration to the person, and not just the process.

Jerry also says that "the cucumber gets pickled more than the brine gets cucumbered." You can only stay in one place so long before you start accepting "the way things are." The people you're trying to help have probably been there awhile.

MWEinNC said...


"Maybe you haven't tried hard enough?" Nonsense! You can't put this on your own back. It's a natural tendency to blame ourselves for failing to convince people to do things that we find valuable, but the sad fact is that (paraphrasing Dostoevsky a bit) people - and organizations - act as they choose to act, regardless of whether or not it makes sense for them to do so, and often in spite of the evidence.

Anonymous said...

I do want to put out there, because this has been on my mind recently - you -are- making a difference. It may not seem that way, and there may not be outward signs of change within that organization - but each person you touch and each idea you communicate is going into people's heads, and it's staying there. It will come back out when it's the right time for that person, or when the right person says the right thing to them at some other conference.

Just because the wall doesn't fall doesn't mean you haven't taken out a lot of bricks. Each one is someone to whom you've offered something real that may help them in the future.

Anonymous said...

I knew what this post would be about before I started reading it, as I have had the great pleasure to work with Dawn.

This organization continues to put its head in the sand--despite multiple exposures to their points of pain. Before Dawn came to this organization, I had feared that this organization was a "ship of fools." Now I know it is. And this ship is taking on water, yet its captain doesn't see or acknowledge this. Ultimately, this ship will sink... Personally, I am glad to see Dawn getting off this sinking ship.

Prior to Dawn coming to this organization, I only knew of "Agile" as something athletes were. In the four months she has worked here, I have learned not only of Agile's value as a software development methodology, but also how valuable this methodology fosters more open human communication, collaboration, trust, and accountability. Dawn has converted me as a change agent--but more for myself than for this organization.

Dawn will be missed.

Justice~! said...

Change only needs to happen when change *needs* to happen!

So wise, so deep! I know. But I'll elaborate on it further when I get a chance to post about it tomorrow!!

Take care in the meantime, Dawn!

Cory Foy said...

Hi Dawn,

Thank you for sharing this post. I've typed up a blog post as a reply - sorry I couldn't make it shorter.

Best of luck to you!


Anonymous said...

Rest assured that you're leaving, having done more than most in the same situation could and, while maybe not all that you think you could do, it's all you could do without losing yourself.

Most of the time, you don't realize it until it's too late - until you've tried too hard, and lost too much of yourself. You spend nights and weekends, fighting for something, some place, someone who doesn't want to be fought for, who doesn't offer anything.

And then, after you've given everything you have, you're left with nothing to show for it, except for hurt.

Yes, you could stay. Yes, you could fight. Hell, I have, for a long time, for a lot of things.

But when there's nothing on the other side, you have to let go, or else you'll end up like me: burnt out, ineffective, and just exhausted.

Be glad you had the wisdom to leave when you did.

Good luck with the next chapter in your life. I'm sorry I won't be a part of it.

Janet Gregory said...

I once left a company when I realized I couldn't change it. I left because I was becoming somebody I didn't like; I was accepting the way things were.

Congratulations on recognizing the need to leave long before you changed who you are and what you believe in.

Markus Gärtner said...

Most of the time I found the three obstacles to innovation which Weinbergs lists in Becoming a Technical Leader:
- self-blindness
- No-Problem Syndrome
- Single-Solution belief

Later he relates these obstacles to the positive aspect of innovation:
- Learning from errors
- Copying existing ideas
- combining good ideas to a more powerful idea

As I learned from "Our Iceberg is melting" - a little fable on organizational change - the first step to change is to raise your point. Show that your iceberg is melting. If suffering from one or all of the three obstacles to innovation, it's unlikely to happen that one sees the neccessity for change on the organizational level.

It's interesting to read about so many people having similar problems as myself.

Anonymous said...


Awesome post. If only more people in development teams were as accutely aware of the problems as you are. I've stood up in front of people like the ones you mention in this post and talked about how agile works. They often refuse to listen, they certainly don't understand and more often than not, they are simply blind to the problems.

Great post. Many thanks for sharing this..

TestyRedhead said...

Dawn, I am so glad you left!

It sounds like leaving was the best proactive move you would make.

I wish I would have done something proactive before the only option left for me was to react. I have every confidence that your next assignment will be a wonderful relief.


Phil said...

Hi Dawn,
Good for you for trying to drive improvement and for realizing when it was time to get out. I hope your new gig will reenergize you.

At our recent Agile Ottawa meeting we discussed a lot of similar questions.

Sometimes the change is just not going to happen. A company at which the culture is not one of striving for improvement sounds like the wrong company for you.

Thanks for sharing and good luck!

Lisa said...

I've lived through a similar situation though not nearly as bad, because at least my little band of testers could function, and apply agile practices and principles to help ourselves. The dev organization tried a couple of experiments, which succeeded, but the culture was too entrenched. When I had the chance to bail, I did.

You know for sure that you tried in the best ways you could find to drive improvements, and you learned a lot, I am sure. In my book, that's success (not for your employer, but for you!)

Seann Hicks said...

This post hits home for me. I am struggling with the same challenge at my organization. I do have some converts (on my team) but not many. What I think is the biggest challenge is that not everyone wants the same things, or has the same concerns. For example, I don't think everyone is necessarily interested in "getting things done". I suspect that some people like to prolong projects - presumably thinking this ensures their job security.

These are the types of fundamental issues that challenge an agile transformation. I wish you luck in the future, and believe that what works and what is right must prevail.

Anonymous said...

While we're doing quotes, here's one from Dumbo: "Sometimes you've got to use a little 'cology. I mean, psychology".

Where technical and management approaches fall down sometimes its useful to use the discipline of work psychology (or I/O psychology as the guys in the US call it).

Technical folk often shy away from it 'cause its too fuzzy, but it sometimes offers real solutions. My mission is to try to change (haha) that. Maybe getting a team of psychologists would help matters.

skim said...

Like Seann Hicks and Dawn, I'm struggling with the same situation except I'm in the beginning of the path.

Is it safe to say you can't change an organization and just move on? Take a shortcut and find another job?

We just had an org change that just made it even more difficult to unify developers and testers as one team and take the whole team approach. Instead, testers are now treated as a service that can be turned on and off when needed.

Jared said...

Sometimes by staying, you cover up the pain that others need to feel before they'll change. :(

I know you've put blood, sweat, and tears into this company. Best of luck with your next move.

Gil Zilberfeld said...

Hi Dawn,

We're doing a webcast called "This week in testing" and in this week's episode, we talked about your post on organization change.

I invite you to see it, and if you like it, please tell everyone you know.


Gil Zilberfeld

Anonymous said...

A lot of people are wondering how you can change such an org. What I'm also curious about is why these people don't want to change. My theory is they don't really like their job. For them, it just pays the bills. With that mentality, I can see it there way:

Becoming agile doesn't happen overnight. It takes a lot of work and practice. That's the first disadvantage from their perspective. And, even if they could flip a switch and become agile overnight, what do they gain?

They still have to work 8 hours a day at a career they don't like. With code reviews, daily stand ups, and pair programming they lost a lot of time to slack. Plus, they have to think harder than they used to, because their sloppy code will make them look bad. Now, when things break, they're accountable instead of it being SNAFU. And so on.

With such a mentality, can you convince them to change? I can't think of anything agile brings to the table that they'd consider a benefit.

That was depressing, I hope I didn't convince myself to become one of them.

TestWithUs said...

SWIFT Interview questions on

For selenium solution visit

For QTP interview questions