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.

It's still a *bug*, and your denial does not change that

UGH!! I've had this frustrating discussion with a developer recently that is really annoying the heck out of me.

In the particular scenario being discussed, this product has a history of not installing correctly. It's a (mostly) .NET desktop suite of programs with a central processing engine. The most common installation errors involve components not registering correctly. The crazy thing about that type of issue is that it manifests itself, for this particular product at least, in fairly inconsistent ways. Sometimes, a user function doesn't work (while sometimes it does!). Sometime, the processing engine locks up unexpectedly.

In the past 4 months, I am certain that I have seen the number wasted man-hours troubleshooting something that ended up being an installation problem climb well into the hundreds. In QA alone, I can cont at least a week, times 3 people. I'm already at 120 -- not counting support, developers, product management ....

There was a customer issue that they had spent the past 2 weeks troubleshooting, only to find out that a file had not been registered properly. So product management asked the developer the following:

Is there an identifiable bug in the installation code that we could track in Bugzilla for inclusion in a future release? Or is this issue a one-off?

And the developer's response was that there was no bug in the installation code, so there was nothing to fix. He went on to explain that the files has just not registered properly or were corrupt. He said that uninstalling the suite should have cleared the problem. (I don't want to copy his response, just because it's fairly product-specific.)

So this was my response to that (I was actually fairly nice in it, because seriously, it drove me *crazy* to see that "it's not a bug" statement!)

Though I can see where there is not a clear bug in the installer, I don’t think that is the same as “we are missing something and should implement some checks”.

It just really seems to me that *any* install that we do should be checking itself, that it installed correctly. I have seen dozens of man-hours wasted in just 4 months, on what came down to things not installed properly.

“It didn’t tell me that it didn’t go right” is a bug, in my book.

Now seriously, let's look at this issue.

If the software does not install properly, that's a bug, right?

If the software fails to install properly, AND does not indicate to the user that *anything* has gone wrong, that's a bug, right?

If this install problem causes the software to not work, that's a bug, right?

Is it considered okay to ask the customer to uninstall and reinstall their product (no trivial task, mind you) when it's not working? Okay, anybody but Microsoft?

Has 10 years of testing led me way far astray from the basics? Am I way off base here?

Lanette Creamer suggested that the developer was right; that it wasn't a "code bug", but rather a requirements failure. This is a valid point, but for some reason, I hate having to "frame" things in a certain way to placate a defensive person.

The bottom line is that this product is doing something it should not be doing, and it is impacting the customers, the developers, the support people, the QA people, the product people ... IT SHOULD BE FIXED. Seriously, don't throw blame, don't deflect attention away from yourself.

Let's instead sit down together and figure out where the problem is and how to solve it.

Harmony is beauty

First and foremost, if you read my blog. I have to suggest that you go grab yourself a copy of Beautiful Testing. It's a great read, and has inspired this post.

I've been inspired by reading this book. I've been reminded of my passion, of the reasons I have chosen to do what I do. After all, I chose to be a tester, I haven't just fallen into a job and decided I should deal with the hand I've been dealt.

I didn't always want to be a software tester. As a young child, I wanted to be a marine biologist! Actually, I wanted to study the neurological systems of dolphins. I was convinced that I was going to figure out what it was about their brains that made them so smart. I still have the book that inspired me then, 9 True Dolphin Stories.

After a marine biology course and choking through learning the ocean zones, I shifted my interest over to genetics. There was something about genetics that was *beautiful* to me. I was amazed at how the whole system *worked*. Granted, sometimes it goes awry, but at an incredibly rare rate. I liked it because it is so *simple*, and yet so completely *complex*. I was amazed at how 4 simple bases could turn into a *human being*. (HA! In the middle of writing this blog post, I went to Barnes and Noble and happened to come across a copy of Matt Ridley's "The Agile Gene"! I'm a Matt Ridley fan, and this title is a re-title, but very coincidental timing!)

When looked at that way, genetics and computers are rather easily related to each other. In genetics, a 4-letter alphabet turns into some complex stuff, like human beings. In computers, a 2-letter alphabet turns into some complex things, too, just not as complex, and too often, not as smoothly. So in a lot of ways, my switch from genetics to computer science was an easy one.

When I work toward making software beautiful, I have in my head a picture of how it's done in genetics. Those systems are exponentially more complex than software, and yet, there has somehow developed a *synchronicity* (Is that a real word?), where even given countless variables, the system is responsive and *works*, regardless of the state of all of those other variables.

Isn't that incredibly beautiful?

Reading Beautiful testing, I saw these same ideas threaded through the chapters.

Matt Heusser talked about math in terms of number theory and proofs, including some commonalities in nature (the Fibonacci sequence and pi, for example). In studying mathematics, Matt found an appreciate for what he calls "aesthetics" (and what I've likely been calling 'harmony'). His sentences on the aesthetics in mathematics hearkened back to my appreciation for genetics for the same reasons.

But it was Chris McMahon's chapter, relating creating software to an artistic performance, that inspired me to think about the way I work on a software team in a new light. He mentioned the way a band rehearses together before a performance. I have seen some *amazing* bands, where I watch them communicate with each other silently. The slightest gestures can be made, some not even perceptible to the audience, and the rest of the band follows suit.

These things happen all over the place! A new mom once told me that she enjoyed me coming over because I "just knew" what she was going to need before she did. Well, of course I did, I've been through the mom thing before. I used to ride horseback (dressage, actually) and with some of the horses I trained on, the *slightest* shift in my body weight caused the horse to change direction. I had to learn to control every muscle in my body to only send the messages I intended. Have you ever seen a couple, who at a party, seem to be able to send signals to each other with just a glance of the eyes?

Coming back to testing and software, it seems that the very best teams work in much the same way. They are able to shift direction, together, without falling out of step with each other. They are able to fill in for each other without the need to go through hoops to do so, and they trust each other completely. They all care about the same things, and work together to accomplish their goals, following the same values.

As a tester, I love the fact that I get to strive toward this kind of harmony, while also managing the effects of so many other variables: the customer, usability, risk, time, cost, value, technology, the business goals, product management, etc etc. For me, being involved in testing means that I have my hands in everything, and spend my time trying to make sure that they *all* work together seamlessly. As a tester, I must represent the customer. I must represent the potential customer. I must represent the developer. I must represent the business. And, I must tie all of these together in an intricate web, ensuring that the outcome represents all of them and is responsive to any variation in their needs.

THOSE are the reasons I am drawn to Agile. THOSE are the things I see in the teams I have had exposure to that I think work *really well*. THAT is why I love testing. Testing *is* beautiful.

The difference between motion and action

I just read this amazing blog post by Steve Blank, and felt compelled to share it.

I'll just post a link now, though I suspect my own spin on it may be coming ...

The Difference Between Motion and Action

Making Quality a Priority

Here is a quick PowerPoint presentation I think may be useful to some other people, too.

The intended audience is business people or executives who still need a little bit of understanding in what it means for "quality" to be baked into every part of software development, from inception through to release, and in what it takes as a team to have the best collaboration between developers and testers.

Please feel free to use it, modify it, etc. And as always, if you have feedback, let me know!

Making Quality a Priority