Testing the Agile MBA

March 27, 2016

man-person-hand-lens

“Research is formalized curiosity. It is poking and prying with a purpose.”

-Zora Neale Hurston

So as I thought about my earlier post on the idea of an Agile MBA, I realized that there is a whole lot that goes into putting together something like that. So before heading down that path, a guy might be well advised to check and see if there is any real interest in the idea before wasting a lot of energy on pursuing it further. So with that thought in mind, I created openagilemba.com.

The idea is simple, taken from the lean startup world. If you have an idea, put it out there and test whether or not there is a market for it. So I’m doing exactly that. Go check it out. I named it the “Open” Agile MBA because I’m not trying to sell anyone anything. What I have in mind is more of an open source MBA model. If we can assemble the resources, then anyone can use them. That’s kind of an exciting idea. It’s not new, there’s a NoPay MBA out there that is really cool and does something similar for a standard MBA.

So I’m starting with small, agile steps. Simply put up a web page and ask people if they are interested. If I get a few responses (feedback!), then I pursue it further, if it’s just crickets, then perhaps I tweak the idea and try again. I can’t wait to find out!


Test Driven Organizational Change

September 11, 2014

change-20272_640

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!

 


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!