Bob The Naked Agilist

August 25, 2013


Have I ever mentioned how much I hate interviews? I absolutely despise them. The average interview is like the worst kind of corporate speed dating. You know how it goes: What are your job qualifications? I like long walks on the beach, Scrum, and listening to Barry Manilow LPs. Seriously, the whole process only serves to dehumanize the participants, both the interviewers and the candidates. The interviewers, utterly devoid of any real information, struggle to obtain some small sliver of insight. The candidates struggle to make themselves as attractive as possible, similarly unaware of any real idea of what the company culture is like. It’s ridiculous.

So there I was in an interview. Things were going as usual. Just sort of stumbling along as they often do. I’m staring at a whiteboard while someone else is asking questions…or somebody is answering one…I can’t remember. Suddenly it occurs to me that we need a visit from Bob the Naked Agilist. So I get up and wander over to the whiteboard and draw this figure:


I call him Bob. Bob the Naked Agilist. No, don’t tell HR. Right now it’s just poor Bob there with no clothes. Just a poor unprotected scrum master with no tools to make his way in the world. The question is: what tools would you give Bob in order to make him a great scrum master? Maybe you’d give him a big pair of boots. You know, something to keep his feet firmly planted in reality. These are going to have to be some big shoes to provide a stable platform not only for him, but for his team as well. So let’s give him a pair right now:


What else would we give Bob? A telescope, so that he can see risks coming? Maybe a broom for sweeping obstacles out of the team’s path? How about a Japanese Katana for cutting the occasional Gordian Knot? Fireproof asbestos pants for taking the heat from project stakeholders right in the shorts? Let’s do it!


Now Bob is starting to look a little bit more interesting. The interview candidate is fully engaged, dressing up their proverbial project manager doll. Me? I’m doodling. And I’m thinking. I’m thinking it’s interesting what people come up with. I’m thinking that I’m learning a lot more than usual from an interview. I’m thinking I’m starting to enjoy myself a little (I love doodling). So after 10 minutes of back and forth play we have arrived at this version of Bob:


He’s quite a handsome devil now! Dashing! Adventurous! Bold! I’m thinking I kind of admire Bob. I’d like to be like Bob. And now I have just finished engaging in a playful game with the person who has come to us looking for a job. Now I have a wealth of information. Now I feel like I have come much closer to full engagement with this person.

I’m swiftly coming to the realization that there are a whole host of things I would rather do than use the traditional interview format (what I kindly refer to as “corporate water boarding”). Games seem like a good start in the right direction. Rather than trying to come up with a masterful set of interrogation questions, perhaps seeking engagement through a short game is a more productive tactic (and more enjoyable for all parties involved). I want an interview that feels alive, that engages people deeply, and that leaves people wanting more.

I know they can’t all be like that, but perhaps we can get closer. Try using Bob. Starting an interview with a naked guy certainly makes them more engaging.

I’m Helping!

August 22, 2013


I used to race with a really experienced crew on a J120 (a flippin’ nice sailboat). We were all very hardcore about our racing. Many on the crew had been racing sailboats since their childhood. These guys were good – really good. We pushed each other hard and we expected a lot of ourselves and each other when we were out on the race course. So there was plenty of pressure.

I came to sailing relatively late in life compared to some, so I was very self-conscious. I didn’t want to make mistakes. In sailboat racing, there are a million little mistakes you can make that will slow the boat down. However, since it’s a team sport, you can cover for each other too. Not only are you trying to perform well yourself, ideally you are trying to help your teammates perform well too (at least on the successful teams). In sailboat racing you are always trying to anticipate what needs to happen next: clear the deck of loose sheets, make sure the spinnaker is prepped for the next rounding, re-run fouled lines, and Lord knows what other details. I always feel a bit like a bobble head doll when I’m racing – always trying to look in every direction at once.

I remember there was one guy on the boat who was really talented. He’d been sailing since he was in diapers. Things just seemed to come naturally for him. He was always where the help was needed most. He was easygoing and relaxed, learning was easy around him. But even he made mistakes from time to time – just like the rest of us. He’d pull the wrong string, blow the wrong halyard, grab the wrong winch. Whenever he screwed up he would yell,

“I’m helping!”

He would do it in an uncanny imitation of the Sesame Street muppet Grover. Super Grover to the rescue! We’d round a mark on the course and he would miss grabbing a sheet (in all the chaos and madness that we call making a left hand turn in sailing…).

“I’m helping!”

Usually everyone on the boat would bust up at this point. It broke up the tension we all felt when we failed a maneuver. It got us past the “Oh shit!” moment and allowed us to shrug it off and keep focused on our goal. I’ve been on other boats where someone made a mistake that cost the team on the race course without the help of ‘Grover’. Generally, on those boats we experienced something that felt like blame and recrimination. Perhaps we were less experienced, less able to forgive each other our mistakes, less able to cover for each other. Less able to allow for normal human nature to express itself. The problem was, we would struggle to recover our equilibrium for far too long after the event occurred.

A couple years later I was on another boat in a long distance race. It was early evening and the sun was setting over the Olympics on Puget Sound. As is often the case at that time of the evening, the wind died and we were left trying to race in the barest breath of wind. The water was flat and the sunlight was turning a deep shade of orange as it hit the mountains and reflected off the flat water around us. In fickle conditions like this, even the smallest mistake can cost you the race. As we all tacked into the shore to get relief from the current, I watched a nearby boat fail to release a sheet and blow the tack. They came to a stop and as we drifted past I heard,

“I’m helping!”

In the unmistakeable voice of Super Grover.

I remember feeling two things at the time:

  1. Damn, that’s funny
  2. We’re going to get our asses handed to us

Frankly I wish I saw more of Super Grover in the Agile software development community. All too often I see teams that are under tremendous pressure to deliver (is there any other kind?). When someone makes a mistake, it can all too easily turn into a situation where blame and recrimination slow the team down. There is no one there to help them shrug the mistake off. Someone with experience and the respect of the team. Someone who can look at his/her own mistakes and laugh,

“I’m helping!”

Sometimes I think that a team needs someone who can see that even though their efforts were well intended, even skilled – they were mistaken.  It is easier when someone you respect and admire can completely blow it and laugh about it. Suddenly the job doesn’t seem quite so serious. The task doesn’t seem quite so critical and we allow ourselves to get back to doing what we really enjoy.

Or perhaps I’ve got it wrong. Maybe this kind of thing doesn’t really apply to software teams. Maybe there is a better explanation for this kind of behavior. If so, that’s OK,

“I’m helping!”

A Violent Introduction to Self-Experimentation

August 18, 2013


It’s early on the morning of December 12, 1954 in the desert near Edwards Air force base. Colonel John Stapp is surrounded by men who are in the process of strapping him to a large metal chair. A warning klaxon sounds and the men retreat. Within a nearby bunker, a switch is thrown and electricity courses toward the man in the chair.

9 rockets fire simultaneously and 20,000 Kgs of thrust are delivered to the sled that the chair is attached to in just under 0.07 seconds. The sled, the chair, and the main lashed to it, leap down the 1000 meter track.

The initial acceleration was so severe that Stapp was slammed with a peak acceleration of 25 G’s – double the pressure that the Apollo Astronauts experienced riding atop a Saturn V

Over the nearly 20 second period of acceleration, Stapp’s face was distorted as the flesh tried to pull away from his skull. His eyes were forced back into his head, and the blood was drained from them, causing him to black out. Particles of sand that he hit as he accelerated to nearly 632 mph pierced his flight suit and his body, leaving burns and abrasions throughout.

He was blind, completely immobilized, and there was no way to steer the sled as he ripped down the track. It must have been like riding one of the four horses of the apocalypse. He set a land speed record that held for many years of mach 0.9. He was traveling at nearly the speed of sound on the barco-lounger from hell.

But that wasn’t the interesting part.

In this case, it was the abrupt stop at the end that was the whole reason for this explosive little journey. As the sled reached maximum velocity, scoops dropped out of the bottom and dug into a trough of water beneath the rails. The sled went from the speed of sound to a dead stop in under 1.5 seconds. The violence of this event for Stapp is still hard to comprehend.

The biomechanics of rapid deceleration were poorly understood at the time, but nevertheless gruesome. The deceleration forces exceeded 43 G’s. Stapp’s eyeballs deformed as they were forced forward and out of the eye socket and there was concern that they would be torn from his head if he didn’t keep his eyelids firmly closed. All the capillaries in his eyes ruptured. His brain sloshed forward within the confines of his skull, knocking him unconscious and leaving him with a severe concussion. He suffered an abdominal hernia and a series of minor bone fractures.

He was severely bruised and battered, but the amazing thing is that he survived the test. So what were they testing? Why in the world would anyone in their right mind subject themselves to this sort of injury?

Stapp was a pioneer in the exploration and discovery of restraint harnesses used by jet fighter pilots for use when ejecting from high speed jets in combat. Stapp was so dedicated to his mission to discover the safest harness for pilots that he used himself as the guinea pig.

He was famously quoted as saying that the only way of determining the point of injury is to go beyond that point. In other words, you don’t know how well it works until you break something – in this case: yourself.

It reminds me of the quote from Mario Andretti, “If you feel in control, then you aren’t going fast enough.”

Stapp’s pioneering work led not only to safety innovations for fighter pilots, but also to the introduction of seat belts in automobiles and passenger planes, in addition to child harnesses and restraints.

So what does this have to do with the way that we work in software? Pioneers like Stapp, whether they are in the air force or software development have always sought the limits of human capacity and endurance. They test the boundaries of human performance using the best subject that they have available – themselves. In fact, many wouldn’t dream of inflicting their wacky hypothesis on their friends, colleagues or grad students without first trying it out on themselves.

To me this reflects a few important things: People like Stapp are passionate almost beyond reason about discovering answers to the problems they are trying to solve. They experiment on them selves for a variety of reasons:

  1. They have courage: they would not ask someone else to take a risk they were not willing to take themselves.
  2. They crave immediate feedback: they are unwilling to accept second hand experience when they can experience the phenomenon themselves.
  3. They are leaders: they will go where no one else would dream of going

That’s nice, you say, but what difference does this make to my team?

First, all too often I see Agile coaches, self-proclaimed experts, and managers all too willing to proscribe how someone else should achieve high performance. My first question for them (and myself) is have you tried this? What direct experience or evidence do you have to support your assertion that we should all do things differently? Why would you experiment on your friends, but not on yourself?

Second, self-experimentation offers us the opportunity for the kind of rapid feedback and resulting learning that can dramatically improve our own effectiveness. Experimentation with groups takes time and persuasion. In the time it takes me to persuade a group to try out a single experiment, I can run dozens of experiments on myself. Why waste the groups time with untested ideas?

Thirdly, we are too satisfied with meaningless incremental progress. We are too comfortable going slow. We have forgotten what it really means to push our limits.

I am fascinated by self-experimentation. The more I look around me, the more I realize that there are endless opportunities for us all to explore the boundaries of human performance.

Whether it is accelerated learning, increased productivity, or enhanced skills, we have barely begun to scratch the surface of what we are capable of doing in software development.

“Most gulls don’t bother to learn more than the simple facts of flight-how to get from shore to food and back again. For most gulls, it is not flying that matters, but eating. For this gull, though, it was not eating that mattered, but flight. More than anything else, Jonathan Livingston Seagull loved to fly.

This kind of thinking, he found, is not the way to make one’s self popular with other birds. Even his parents were dismayed as Jonathan spent whole days alone, making hundreds of low level glides, experimenting.”

This is the experimental mindset we need to have in order to grow to our fullest potential. It is reckless, it is personal, and it is passionate almost beyond measure.

I have a confession to make: I crave the day that someone comes up to me, hands me a helmet and a mouth guard and says, “Strap in Tom, we’re going to do some pair programming”

So Bolt me to the chair

Light the rockets

Hang on tight and lets find out what we are really capable of!

Experimenting with Cadence

August 15, 2013


Recently I’ve taken up running again. Don’t worry, this isn’t some story of how glorious it has made me feel. Running sucks. I’ve been doing it for months now, and I’ve yet to have that stupid runner’s high that everybody talks about. I just feel moderately like crap when I’m done. At least that was the case until today.

Finally I managed to have a good day! I felt great. So what was different about today? Well, the pace was a little different. I altered my stride just a little bit. Held back a little. Focused more on each step. It felt like I was taking more frequent, smaller steps to go the same distance. Don’t get me wrong: I probably look like a fat man who is angry at the ground when I run. I’m nobody’s expert on running.

Regardless, it got me thinking about cadence (hey, I was bored and hyperventilating). It seemed like changing my stride, altering my cadence, might have a profound effect on my experience of running. Of course this should come as a surprise to absolutely no one. The sports world is full of great examples of the power of finding the right cadence. Apparently in cycling (another sport I know nothing about) Lance Armstrong’s magic pedaling cadence was responsible for some of his amazing performances in the mountains. Well, OK…it was that and a boat load of drugs. Maybe I’m doing it wrong…

But back to cadence: we all grow accustomed to doing things at a certain pace that is comfortable for us. Whether it is running, walking, working, writing, or chasing the kids, we all have a certain pace that we tend to move at. How could we change our pace in a fashion that might allow us to experience the work or the exercise differently. In the case of exercise, speeding up and slowing down is usually not all that hard to do. The cadence we use and the mechanisms we use to control it are fairly obvious: we shorten our stride, we don’t push quite as hard. Unfortunately, in the world of work the notion of cadence is a bit more subtle.

Take programming for example. One way to measure cadence is working sessions. Some people will use practices like the pomodoro technique to break up their work day into 25 minute blocks of working time with 5 minute breaks. Another example is the “pairing session” where you work together with someone else at pair programming for a fixed period of time (say 60 minute blocks). Now it might be good enough to just settle on a time that seems comfortable and run with it. However, I think there is an opportunity to experiment with cadence here. Let’s look at the pomodoro: why is a 25 minute working session the best length for you? Why couldn’t it be 20 minutes – or 30? How would you know which works best? By trying it out of course! If  you want to find the cadence that works best for you, you need to experiment with it and see how it feels.

At this point it’s probably worth mentioning that you aren’t likely to experience a runner’s high from programming (otherwise there would probably be a lot more people doing it). However, you might just find that you can sustain the work for longer overall durations by finding the working period that is tuned to what feels best to you. That would be a win wouldn’t it?

So don’t be afraid to play with your cadence. You just might find that you are able to find a mode of working that works better for you.

Pervasive Language

August 14, 2013


I was watching a movie with my brother the other day and the rating warning came up, “Rated PG-13 for Pervasive Language”. I found myself scratching my head and wondering: what the hell is pervasive language? Maybe the people in the movie are going to talk a lot? Perhaps it’s just two guys talking to each other like in “Dinner at Andre’s”? I couldn’t help thinking, “This is going to be really boring…”

Actually I’m kind of an expert when it comes pervasive language. You see I’ve got kids and they never seem to stop talking. I go to Agile conferences, and brother do those folks ever talk a lot! You just can’t shut those Agile people up. That’s what we mean by pervasive language, right?

As a sailboat racer I’ve heard an awful lot of pervasive language (of the pirate variety). You hear it out on the race course all the time. It  is interesting to see the way the quantity of dialog changes based on the experience of people on the boat.

New/Green crew – There is an awful lot of talking going on:

“Get the sheet!”
“No, the other sheet!”
“It’s right there in front of you!”
“No, not you, damnit!”

The chatter is virtually non-stop and it can easily escalate to screaming when there is a little stress. The language is certainly pervasive. It is all about how to do the work and very little talk about heads up thinking about strategy or weather. Being on a boat with a new crew demands a lot of patience and a huge amount of talking.

Old timers/Experienced crew – There isn’t much talking at all. There is never screaming on these boats. It’s like everyone on the crew is part of a collective Vulcan Mind Meld. Everyone just knows what to do. When something changes, the whole group knows exactly how to react with a minimum of information exchanged. When there is discussion, it is strategic in nature, “The wind looks better over there…” These are the teams that just quietly and efficiently kick your ass on the race course.

It strikes me that there might be similar patterns of communication on software teams.

New teams have a lot of chatter as they go through the usual forming, storming and norming patterns we have all come to know and love. There are lots of questions and debates about the way things are done, who is doing what, how the work is done, etcetera. Cram all these people together in a common room and you have a recipe for some real noise!

Older, more experienced teams are much more likely to be quiet workers. I’ve worked with some teams where you would walk into their room and all you would hear is the ghostly clicking of keyboards. Everybody was deeply engrossed in their work and making progress.

Of course there are exceptions to these rules. There are teams that are just naturally composed of noisy, gregarious people. Others are naturally quiet. But the broad generalization does seem to hold true.

Now there are some times when you will hear the experienced crews/teams become noisy: When they are learning something new. Introduce a new element that they haven’t had to deal with before and listen to the chatter level rise. It might be caused by the introduction of a new team member or perhaps a new tool (like a new asymmetrical spinnaker). Once we are kicked back into learning mode, the need for communication on the team rises dramatically.

The point I’m trying to make here is that the level of communication that teams engage in is heavily dependent on things like experience and context. Don’t make the mistake of judging a team’s communication simply by how pervasive the communication is (it is equally foolhardy to judge a movie for the “pervasive” quality of its language). Experience, culture, context and personality all play important roles influencing the ways teams communicate with each other. Even beyond all that, there is the question of the quality of the team’s communication.

So what kind of noise is your team making? A roar? A whine? Or are they just humming along?


The New Science of Building Great Teams, Harvard Business Review