Be Like Beaker: Experiment on Yourself

January 31, 2013


“Bunsen Honeydew here at Muppet Labs where the future is being made today.”

As a kid, as soon as I heard those words from the good professor I just knew that something awful was going to happen to his poor hapless assistant, Beaker. Beaker knew it too, that was the really hilarious part about this Muppets skit. His pitiful, terrified protestations to whatever sadly misinformed experiment the professor was going to inflict on him kept me rolling on the floor laughing. Being able to see the inevitable outcome a mile off just made it even funnier. You could see it, Beaker could see it, and Honeydew didn’t have the faintest clue.

Even as an adult, watching Beaker on the Muppets makes me laugh so hard I avoid milk for fear of being caught spraying it out of my nose.

Of course that’s why you have a trusty lab assistant isn’t it? You need somebody to experiment on, right? When you have a truly brilliant hypothesis – we’re talking real genius here, what you really need is a willing subject to perform your tests on. What could possibly go wrong? After all, how else do we expect science to progress? I’ve seen a lot of Bunsen Honeydews in software development. Shucks, I’ve played one myself. For 50 cents and a cup of coffee I’ll teach you how to be a Honeydew too.

Unfortunately, for almost every professor Honeydew there is a corresponding poor schmuck playing the role of Beaker. Maybe it’s just one person or maybe its a whole team (If you’ve ever experimented on an entire team, you are hereby entitled to call yourself an “agile coach”). Sometimes it seems as though every lead, manager and coach has to go through a Honeydew phase, blindly inflicting their experiments on others.

Let’s face it: having your very own lab assistant to experiment on is great if you can manage it (you lucky dog). But what do you do if you don’t have a Beaker handy – or the wily creature keeps running away. What then? Well there is still one test subject available: You.

Yeah, you.

“What? No!” I can hear you exclaim. Who in their right mind would experiment on themselves? Well, as it turns out, there is a rather curious and rich history of the famous and infamous who have performed experiments on themselves. And we’re not talking about trivial stuff here either. Many of these experiments represent real and substantive contributions to the body of scientific knowledge.

Benjamin Franklin is an early example of someone who performed self-experiments. He tracked how well he was able to dedicate his full attention to the “Thirteen Virtues” for an entire week. Anybody want to try to dedicate their attention to the 12 Principles of the Agile Manifesto for a week? I tried once and learned some very interesting things about myself and the manifesto.

Another example, Dr. Albert Hoffman accidentally discovered the psychedelic properties  of LSD and then subsequently experimented with it on himself. Wow! Me too!

Of course fiction is full of less fortunate examples of self experimentation. Take for example, the tale of Dr. Jekyll and Mr. Hyde or The Invisible Man. One hopes we are not so unfortunate in our own efforts!

One of my professors in college was an advocate of self experimentation. He tried sleeping each night with the head of his bed tilted toward the ground so that the blood would pool in his head as he slept. He reports that it gave him a tremendous headache.

You might laugh at that last example, but it highlights a very important point that I want to make: When you test out ideas on yourself, you can get rapid feedback on what may pay off and what won’t – all without inconveniencing anyone else! It’s brilliant! That’s what my college professor realized. He could perform dozens of tiny experiments in the time it took to set up a single experiment with a population size much larger. Its that ability to try multiple small experiments in order to gain rapid feedback that lies at the heart of all the agile methods!

So why would you waste your time trying to persuade a recalcitrant team to try out your latest hare brained process, when you are perfectly capable of proving it much more rapidly yourself? Not only can you quickly validate your ideas, but you can also refine them much more rapidly by yourself, so that when you do finally reveal them to the team, they have had some refinement prior to being inflicted on others. Hell, they might even work!

Aha! You pounce, you can’t possibly achieve statistical significance with a population of only 1 can you? Well, I’m not necessarily looking for rigorous statistical significance here. I’m keeping things simple and using simple statistical tools (time plots, etc.) to capture just the information I need to discover if I’m “moving the needle” in the right direction. Also, repeated measurements and an ABA design can go a long ways toward validating these simple assumptions.

What about your objectivity? Phah! I don’t need no stinking objectivity! In fact, because it is just me, myself and I, we can take advantage of subjective measures much more readily than you would in traditional large population experiments. Questions like “How do I feel today?” have easy, subjective answers that can prove just as useful as traditional objective measures.

Furthermore, with the advent of mobile devices with rich applications and interfaces we are now starting to see the development of an entirely new class of self-measurement devices. Nike has the “Fuel” bands, my iPhone has mood trackers, workout trackers, pulse monitors. The list of applications is growing with astonishing speed. It is actually leading to a movement of sorts that labels itself the “Quantified Self” movement.

In this new ecosystem of rapidly evolving new tools we have a new wealth of opportunity to experiment with ourselves. With the combination of agile methods we have the ability to rapidly iterate through many tiny experiments on ourselves and help to refine the techniques that we can use not only on ourselves, but on our teams.

Now is your chance to make yourself part of science. Explore your inner Beaker!


January 29, 2013

In the sports world there is a fairly well understood phenomena known as “over-training”. In broad terms, over training occurs when an athlete trains harder than their body is capable of adapting. It’s generally characterized by a decrease in performance, changes in mood, physiological changes like weight gain and chronic soreness. The remedy for this condition is to back off on the training and slow down. Simply put, the body needs a chance to recuperate.

This is something that is so common and well understood in the sports world that almost any good athletic coach knows what it is, how to spot it, and how to treat it. You see it all the time when you go to the gym. People pounding away on exercise machines, full of vigor and enthusiasm and guess what happens?

Day one – Work out like crazy.
Day two – Ooh sore, keep working out like crazy.
Day three – Still sore, push through the pain.
Day four – No energy, flail through it all based on raw drive.
Day five – Wondering why you ever thought this was a good idea.
Day six – God I hate exercise.
Day seven – You pull a hamstring and limp off to the doctor.

That’s how over-training works. This story is so common that I would be very surprised if anyone reading this has not personally gone through exactly those steps at least once. I know – I have done it myself many times. What’s the first thing that you would tell someone who had just gone through this hypothetical 7 days from hell? Slow down! Pace yourself!

That’s right, it’s so simple to see the pattern that just about anybody could spot it. Who is the one person who can’t see what’s happening? Yes, you got it: the poor guy doing all the work (just too busy, busy, busy). At this point, unless our hero is some sort of expert in physical fitness, he’s probably well advised to seek the experienced help of a trainer or coach.

So that’s fun. Can we over-train elsewhere? Playing the violin? Studying for an exam? Writing code?

I had a friend once who got his first job as a software developer at a small Seattle startup. That was back in the heady days before the boom. He was so excited he could barely contain his enthusiasm. He was going to be working with some of the best developers he had ever met on exciting projects that were going to transform the way we work with computers. It was huge, audacious, and magnificent! He dove in and gave it everything he had. He was so eager that he got up at 5 AM to catch the first bus downtown. He read programming books on the way to work. He coded non-stop until 10 at night and then studied more programming books on the bus home. Six hours of sleep, rinse and repeat. Often on weekends.

For over six months straight.

And then I was my friend was laid off. Poor bastard. So, because I just happen to know this guy pretty well, let’s see if we can ask a few questions (and fortunately he can’t read because he went blind reading programming books on the bus). First, were there any signs of over-training to be found? Why yes there were! As it happened, he started to suffer some anxiety – constantly worrying that he wasn’t achieving enough, not smart enough – the pace was starting to grind him down. His performance started to suffer: his hands might be on the keyboard all day long, but there were increasingly long stretches spent just staring at the screen (not to mention drooling on the keyboard). Weight gain? Check! Twenty pounds, easy. He even developed a mild case of carpel tunnel syndrome. Soreness? Check!

Pretty much a classic case of over-training. And the prescription? Slow down! People told me him to slow down and guess what? It really didn’t help. He couldn’t understand what “slow down” meant. You might as well have said it in Martian. I could see the lips moving, but the words made no sense. How do you explain “slow down” to someone who can’t ever go fast enough? Can’t be done. I had deadlines. The team was depending on me!

The irony of what ended up happening was epic.

The pace that we keep, no matter what the endeavor, really seems quite important. Do it right and you can sustain your pace like a marathon runner. What is most intriguing is that just like in the case of athletics, there are tell-tale signs of over-training in knowledge work. We can and should keep an eye out for those signs. It’s also apparent that, despite a relatively simple prescription (slow down) it can be a tough nut to crack.

So, if I could go back and coach this friend of mine, what would I tell him? What would I say as someone who has seen this pattern before? What would I say as someone who has experienced it himself? I probably wouldn’t say anything. I’d probably just give him a hug.

…And tell him to avoid redheads named Heather
…And don’t play that stupid drinking game with his brother
…And for Pete’s sake, BUY APPLE stock!


January 28, 2013

The other day I was re-reading Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. I was looking for a metaphor for quality used in the book that I remembered reading long ago. I found myself sucked into the book almost immediately and I stumbled across a quote that caught my attention.

Mountains should be climbed with as little effort as possible and without desire. The reality of your own nature should determine the speed. If you become restless, speed up. If you become winded, slow down. You climb the mountain in an equilibrium between restlessness and exhaustion. Then, when you are no longer thinking ahead, each footstep isn’t a means to an end but a unique event in itself.

This gave me pause. You see in software development, this kind of thinking is completely alien. Maybe that’s too broad a generalization, so let me refine that statement a bit: for me, that notion of equilibrium and balance is foreign. You could say it’s all the same. I’ve grown up in the software business. I know how to work all night to hit a deadline, to “sprint” toward a goal. I’ve been doing it for 20 years.

And boy, sometimes I get tired. Really tired.

I once told someone that I have no right to preach the merits of sustainable pace to anyone – because I can’t seem to do it myself. Recently, in a rather dramatic turn of events, I collapsed just prior to a speaking engagement. The pace, the pressure, and the travel just added up to too much. Fortunately, that’s all it appears to have been – stress. Thank God.

But I was left with a compelling desire to…sit still for a while.

It occurred to me that the mountain wasn’t going to go anywhere, so I might as well take a break.

The really curious thing was that I was still restless. I had just been delivered one of life’s little telegrams with the message, “Slow down or die.” I figured most rational people would pay some heed to a message like this. Apparently I’m not a member of that clique (the rational ones). Now this doesn’t come as a remarkable surprise to me, but I did face this revelation with some curiosity.

The question is, why the hell can’t I slow down? Maybe its the business I’m in. Let’s face it: software development is all about going faster. Call it Scrum, call it XP, shucks I really don’t care what you call it. The bottom line is that it’s all about delivering value faster. Of course value is also what Pirsig’s book is about, the subtitle being, an Inquiry into Values. So what are my values? Is delivering fast one of them?

If I look at the agile manifesto, a document that can be fairly said to have influenced my work life quite substantially, I read the following:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Well, there is no reference to going faster that I can read into that. Now you might argue that the principles might state otherwise, but on the face of it, the values don’t have anything to say about how fast we delivery software.

Of course with all the running about that I tend to do, it may just be that I’m a lot lower down on this metaphorical mountain than I had previously thought. You see, I’m not sure I’ve had much practice at this stopping game.

Maybe it’s like this: when you learn how to ride a bike, the first thing you learn to do is learn how to get going. How to get started. How to initiate the process. Once we do that then we need to learn how to keep it going. How to sustain our progress and navigate through unexpected turns. Finally, we need to learn how to stop. It could be a gentle glide or a power slide, but stopping is just as important as starting.

Frequently I see teams that in some very important ways seem to have mastered the first two steps, but seem to struggle when it’s time to stop. There are all kinds of reasons to stop when working on a team. For instance:

1) at the end of the release
2) at the end of the day
3) at the end of the sprint
4) when something goes wrong or breaks
5) when someone notices something out of the ordinary
6) when the team is done

The funny thing is, like a lot of things that I observe on teams, I see these reasons for stopping in myself too (I have a list of things to stop that is very nearly ten times that long). So I have become very curious about this “stopping” thing. Frankly, I find it all a bit terrifying. It feels risky to think about stopping. So I’m approaching it with due caution. Dipping my toe in the slow pool – starting with some meditation.

So, I take the time to stop and do nothing a few times a day. I just sit there and listen to the hum of the world whizzing by. I’ll be honest, I can’t tolerate it very long before I am sucked back into the frenetic pace of “the game”. It’s an experiment. An attempt to practice that crazy stopping thing. I have to admit it’s kind of nice…sometimes.

So, that’s where I’m at. This post has meandered and digressed and gone nowhere in particular. That feels about right. This is probably a good place to stop.