Test Driven Organizational Change

September 11, 2014


Let’s just say I was testing the bounds of society. I was just curious. –Jim Morrison (1943 – 1971)

I’ve been contemplating experimenting with some change, but I’m not really sure what is going to work and what won’t. In some ways that dilemma mirrors my coding style. Often when I embark on a project, I’m not entirely clear whether or not what I’m doing will work or not. I mean, I think it will work…but I’m really not absolutely positive. When I code…stuff happens.

I guess I could be accused of rushing into coding without taking care to fully think the problem through. But when I’m swept up in the moment, I want to run with the momentum I have. Call me impulsive. I admire others who have the self discipline to worry through the analysis before they get started, but that’s just not me.

That’s why Test Driven Development has been such a lifesaver for me. It forces me to think about what I’m trying to accomplish before I write the code. It gives my approach a little rudimentary discipline, rather than simply stampeding into the code. Moo.

The question is, can I use TDD to help with organizational change? What would that look like? In order to do TDD we have to start by asking ourselves what the expected outcome of this process or change is. In terms of team performance, that might mean a change among many different metrics (i.e. velocity, throughput, etc.). So first you set up the test: what would the desired outcome of the change be? More software? Happiness? Safety? Openness? Joy? Perhaps it is the absence of something?

Example Change: I want to bring more openness to new ideas to our work.

Next, what are the things that would indicate success? A change in the number of releases? A subjective rating of mood? Maybe a count of unsolicited ideas? Keeping a resistance index (a count of protests per session)? A count of positive/supportive statements. Basically we are looking for some kind of measure that might give us an indication that we are passing our test.

Example Test #1: I will count new ideas that come up in team meetings on a daily basis – If the count is greater than 10, then the test passes


Wacky thought: would it be possible to measure all behavior change in relation to changes in code? How would a subjective notion like enhanced social safety within the team be reflected in the code base? Whoa…I think I just bent something important in my head when I bumped into that last thought.

Of course, just like for code, you probably wouldn’t write just one test for any given change. Like code, change is complex, so we are going to be well advised to create multiple tests for any given single proposed effort.

Example Test #2: I will count the number of new ideas that get shot down daily – if the count is less than 3, then the test passes

Great, now we have some tests, what next? Well in TDD we run the tests first and verify that they all fail. Yes, Martha, all the tests are red. Good! Now, and only now are we ready to create change.

Example Test Run: Day one, test 1: result is 4 new ideas – test fails. test 2: the result is 4 – test fails. We are red.

So we put our change initiative into place. But wait – we must keep in mind rule #1 of test driven development: do only the very simplest thing to pass the test. What does that mean? Well if you want people to be happy, what’s the very simplest thing we could do? Would you go to HR and initiate some sort of peer reward system complete with executive buy-in and a roll out program with sensitivity training? Or…would you make a point each day of telling someone how much you genuinely appreciate working with them? Remember, rule #1: KEEP IT SIMPLE!

Example Change: Add a new rule to the team agreement – you can’t say “no” to a new idea.

Then we run the tests again. Where do we fail? Where do we pass? Now we might have some interesting information!

So, before I forget, there is one last thing we should do: refactor. Now we need to go back and take a look at those tests and see if we can improve them. We also look for ways to improve the changes we made. Maybe instead of telling people how much you appreciate them, you give them a hug instead.

Then just like in TDD, we go back to #1 and repeat.

Of course we can’t call this Test Driven Development because that name is already taken. Maybe we could call it Test Driven Change? TDC…Yeah, that could work. Let’s call it Test Driven Change – if I can get three people to do it, then we’ll call it a movement!


Inspired by Executable Design

December 16, 2008


A post on “Executable Design” from Chris Sterling inspired me today. I’ve started running TDD workshops with the teams that I work with. It’s one of the most challenging things I’ve done in a while. Part of the challenge lies in exercising my technical skills – nothing exposes you to a group like coaching directly on coding techniques. Developers can smell your fear…

However I find that technical issues aside, acceptance of TDD lies in doing a lot of listening. And I mean a LOT of listening. As Chris states so eloquently, TDD is not a silver bullet that should always be used regardless of the circumstances. When someone is objecting to using TDD, there is often a darn good reason for it. Sometimes they just fear change, but as often as not, I find that people have realistic concerns about the appropriateness of using TDD in the particular environment they work in. Ignore them at your own peril.

Most of the time people understand the merits of TDD quite quickly – let’s face it, it’s really quite simple: Test. Code. Refactor. Repeat.

The merits of the process are not what people usually have problem with. Usually they are envisioning what happens when they try to apply it to the environment they are currently working in. That’s where the rubber meets the road. You have to be willing to listen to them, take their reservations seriously, and venture into the dragon’s lair (the environment they work in) to understand what they are dealing with. It’s very hand’s on. Very messy. Fraught with challenges.

Very quickly you can discover that TDD is not an all or nothing proposition. If people feel like you hear and understand their reservations and concerns, then they will probably be willing to follow you down a path toward some sort of adoption – if there is measurable  benefit. They may be willing to explore a variety of useful but perhaps imperfect solutions. On the other hand, if you are just regurgitating the benefits of TDD and dismissing fears…well, I’ve tried it and not had much success.

Hanging My Test Driven Christmas Lights – A Retrospective

December 7, 2007

OK, so by now, many have read my first missive regarding my annual sado-masochistic ritual of decorating the house for Christmas. I’ve just finished the whole embarrassing production once again. Time for a little retrospective:

So let’s start by reviewing our objective…

Goal: To win the Elf Award for the best Christmas lights in my subdivision so that I can revel in the glory and adulation of my neighbors and idle passers-by.

What Went Well:

  • More lights than last year
  • Key display items repaired (“Frosty is back!”)
  • Ten Fingers, Ten Toes, Skull still intact, No broken bones
  • No visits to the ER
  • Fewer unexpected blowouts – improved quality
  • Still married

What Could Change:

  • Casualties: 3 fingernails & one stapled thumb
  • Work more closely with the product owner
  • Get approval for changes to the lighting scheme BEFORE implementing

All in all, this year’s lighting experience has been much better than last year’s. There are a few things that might explain this success beyond what I talked about last year. This time I did the work in much smaller chunks instead of trying to do everything in one day. This made the physical exertion seem much less.

I should have gotten approval from the product owner for smaller increments of the work. I had a few scares where my wife came outside, looked at the fruit of my labors, and said, “You’re NOT going to hang icicle lights on the tree are you?”

Of course not, Honey…

Of course the real approval for this release will come from the judging committee when they hand out the Elf Award. Maybe I should bake some cookies for the committee? Should I greet them at the door wearing a tie? Should I write an acceptance speech? Stay tuned.

Hanging My Test Driven Christmas Lights

November 26, 2007

Every once in a while I have one of those, “Science catches up with reality.” moments. Take, for example, this weekend. I was putting the Christmas lights up on our house. You know, that yearly ritual where an otherwise sane man will risk life and limb in the pursuit of putting more lights on the outside of his house than his neighbor has. I fall victim to this peculiar form of insanity about once every 12 months. So there I was, cursing as I disentangled myself from a particularly aggressive set of C9’s. I was just about done. Icicle lights along the roof line, LED’s along the garage, rope lights arrayed down the driveway, lighted Christmas tree and snowman in the front yard – my chest positively swelled with pride. All I had to do was to plug it in and survey this masterpiece of suburban manhood. I stick the plug in the socket and I hear a “pop!” as the fuse in the snowman blows, and then I look up to notice that half the lights on my roofline are not lighting up. Cue more vehement cursing.

I had broken the first rule of agile development – Test First! Of course, any reasonably competent handyman would have known to try plugging in each strand of lights before beginning the life threatening task of suspending them from the roof – right? As I stood there at the foot of the ladder and contemplated my predicament, It occurred to me that the consequences of failing to test in the real world are a whole lot more painful than in the digital world. It’s really quite amazing that Test Driven Development hadn’t come along much earlier. If you stop and look around, people are doing it everywhere! Doing some woodworking? Measure twice, cut once.

Why did it take so long for us developers to catch on? Perhaps it is just because in the digital world, the consequences of failing to test your work really don’t have any physical pain associated with them. Anguish maybe, but pain? No. Was I going to be in pain replacing those lights? Oh yes.

I’ve always suspected that every developer’s chair should have a Taser installed in the seat. Broken build? Bring on the voltage baby! Maybe a more severe appreciation for the consequences of breakage is what we all need. As I returned to my roofline to retrieve the dead strands of lights, I realized that even the most trivial activities can benefit from the application of Test First or TDD. After all, if you had asked me, I would have described putting lights on the house as anything but a challenging intellectual activity. Hah! now I was the idiot desperately clinging to the frozen eves of my own house, praying that I wouldn’t fall. As my flimsy ladder shifted beneath me, my life flashed before my eyes like a bad ‘B’ movie (very boring – gotta get a new writer) I realized the error of my ways.

To make matters worse, I had a string of lights that would sort of randomly turn off if I happened to jiggle them just right. My tests on the ground would prove they were fine, but then if I moved them a little, they just might just as easily test as bad. What can I do to solve this problem? Test first doesn’t do me any good here. Then I had an epiphany: why not use Continuous Integration! If I leave the lights on while I’m hanging them, then I can always visually see if I’ve created a problem as I’m in the process of hanging the lights. Cool! I can make changes to the layout of the lights based on the feedback I get as I actually lay the strands out. Blow a fuse? No problem, time to rethink that strand arrangement. So now I’ve managed to incorporate two principles of agile development into my process for hanging Christmas lights: Test Driven Development, and Continuous Integration.

I know what you are thinking – this guy seriously needs to get a life.

But honestly, I think it helps to try and find examples of these principles in your daily life. As we focus more and more on changing our fundamental paradigm for software development from waterfall to agile, we need to keep seeking validation in the “real” world. Look to other disciplines, look to the mundane, the everyday things that we do. Check and see if the premises that we use for Agile Development apply elsewhere. So, the next time you find yourself facing one of those everyday challenges, take a moment to reflect on whether the application of a few agile principles might be just the thing to help you out. And who knows, you might actually get those Christmas lights working…

Merry Christmas and Happy Testing!