Culture Eats Impediments Too

March 3, 2014

hippo

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Action can’t be taken because projects are too important to risk
  • Only certain people can take action

I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…

Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.

The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

 


Prerequisites for a X-Functional Team

November 22, 2013

nfl_u_bironas_300

I have a confession to make: I’m a huge football fan.

Every Sunday you can find me glued to the TV watching the high drama we call the NFL play out like gladiators in a Roman coliseum. It’s a gorgeous spectacle. The other day I was watching a game where the team was punting to the Hawks. The kicker, a specialist if there ever was one, dispatched the kick and then all hell broke loose.

The receiver, some professional 800 pound wrecking machine of a human being, caught the ball and proceeded to mow his way down the field. This guy was in Beast Mode. He was flinging 300 pound linemen left and right like rag dolls. In short order it was apparent that there was only one thing left between him and the goal line: our hero, the kicker.

The kicker, wearing only one shoe. The tiny little kicker, with shoulder pads that are probably best described as vestigial. This one scrawny guy was the only thing in between a rip-snorting, fire-breathing, brahma bull and the goal.

Right before he tried to tackle the coming human freight train I remember thinking, “You poor bastard.” As you would expect, he was cast aside by the rampaging helmeted monster like a toy.

After the play, the kicker got up, bleeding and concussed and headed for the sideline. You couldn’t blame the guy for thinking, this ain’t my job. I don’t get paid enough for this crap.

But he did it anyway. Let’s face it, anyone can tackle somebody. All you have to do is spread your arms wide and kiss your ass goodbye. We all have the tools required to do that.

And that’s what makes cross functional teams work. On a cross functional team we all have a minimum set of skills that we can all use. Like our kicker, we aren’t all equally skilled at using them, but we can do it in a pinch. If we have too.

The more I thought about that, the more I realized that this is just as applicable to software teams as for football. In order for a truly cross functional team to work, there must be a common underlying set of skills that is shared by every single member of the team. No exceptions. None.

Any member of a truly cross functional software development team must be able to do the following on demand:

  1. Pull the latest version of the code from the code repository
  2. Build the code from scratch
  3. Deploy and configure the application
  4. Build the tests
  5. Configure the tests
  6. Run the tests and be able to understand the results

Every single member of the team needs to be able to do all of the above. Everyone. That means:

  1. The project manager
  2. The developers
  3. The QA
  4. The Release Engineer
  5. The UI guy
  6. The Documentation specialist
  7. The Business analyst
  8. The Product Manager
  9. Did I mention everyone?

You don’t have to know how the code works. You don’t even have to know how to program (although that helps). Each of the tasks I listed is entirely mechanical. You could train a rat to do any of those tasks (with enough food pellets). They are the bare minimum necessary to contribute to helping a cross functional software development team get their work done.

You may even use tools to help make each of these steps nearly automatic (if you are on an especially bright team). That way you minimize the training required for someone to join the team and help you out. You automate the overhead so that any idiot can build the product and run the tests. This makes it possible for others to help you. It lowers the barriers to entry and creates the opportunity for others in your team to help you out.

If you can’t do these things, then you have barriers to helping each other out. If you don’t even know how to build the code, then there isn’t even an opportunity for you to contribute. These things are basic. No, they’re even more important than that, they are primitive. Learning these fundamentals should be part of joining the team for everyone.

So, is your team cross functional according to this definition?


The Agile Experience and The 5 Rules of Accelerated Learning

October 4, 2013

Five_rings

How do you experience Agile?

I’m not talking about the process, the rituals, or the artifacts. I’m certainly not asking you to regurgitate any of the usual Agile jargon. I’m talking about how it makes you feel. It usually starts with a question like, “Are you using Agile?” and I catch myself saying things like, “Yes, we do scrum.” Answers like that probably miss the point on a very fundamental level. What I think some people are really asking is, “What does it feel like to work at your company.” What is the experience like?

All too often, that’s as far as the conversation goes. I find myself frustrated by that. You see, I want people who come to work with me to have an experience that is different from the traditional corporate environment. I want them to feel differently. I want them to interact differently. You see, I think a different experience was behind much of the promise of agile methods. Agile provides this groovy toolbox of collaborative methods in order to help change the way working together feels. It promises to change the experience of work.

Just using Agile methods won’t necessarily generate a different experience. You can just go through the motions and not change the feeling of the experience at all. A planning meeting where everyone is seated at a conference table falling asleep in front of some task board on a projector feels a whole lot different from a planning meeting with everyone standing up talking and trading sticky notes back and forth. Its a visceral difference in the experience. You can call them both agile planning meetings, but one feels very different from the other. I see this all the time in daily stand up meetings. Poorly handled stand up meetings usually have all the life and energy of a funeral.

How do we change that experience?

That’s where Willem and Diana Larsen have some interesting ideas. They are working on a book enigmatically entitled, Name This Book that among other things introduces the Five Rules of Accelerated Learning. These rules offer a foundation for techniques that we can use with our teams to enrich the kind learning they have to do every day. These are ideas for improving the learning experience along 5 different dimensions: Alive, Fluency, Signal, Focus, Setting. Each of these dimensions interacts to contribute to the power and effectiveness of the learning experience.

Willem puts it best “I always recommend thinking of the Five Rules as two Values (Alive and Fluency) and three Principles /Tools (Signal, Focus, Setting), and listing them in a consistent order for that purpose (Alive, Fluency, Signal, Focus, Setting). This also makes them easier to recall for new folks”

They also have a smaller 99 cent book that just gives a summary of the Five Rules that you can find here: https://leanpub.com/fiverules. If you are just looking for a quick intro, this is where you could start.

In brief, here are the rules:

Alive

This is about the feeling of energy in an experience. As Willem and Diana put it, this is that feeling of having a peak experience. That moment of total engagement or achieving flow. There is an element of playfulness to it. We want to maximize this feeling in order to enhance  learning.

Fluency

This is the assessment of our skill at actually doing something. In order to provide the right learning experience, we need to assess the fluency of the learners, and perhaps more importantly, create simulations that challenge and allow them to exercise or experience that skill.

Signal

Changing the signal is about amplifying the message so that the learner is most likely to receive it. This can involve reducing distractions, increasing repetition, upping the emotion – using every tool at your disposal to get their attention.

Focus

Keeping learning going requires steadily adjusting the focus so that you accomodate the varying attention levels of your audience. This involves changing the pace, breaking things up and adjusting based on the overall energy level (see aliveness).

Setting

Altering the setting is creating the environment that promotes learning. It’s all about an environment that enhances or amplifies the learning that takes place.

Putting the 5 Rules to Use

First, if you are interested in this sort of stuff,  you should check out their book. They do a fabulous job of laying out all of the rules and putting them in context. Second, if you have a chance, you should definitely catch a presentation on the topic by either Willem or Diana. They are two very engaging speakers and I’ve heard them speak on this subject – it’s worth it. Finally, even if you don’t do any of the above, it’s interesting to note that Willem has put all of this theory into action with Language Hunters – a learning group dedicated to using these techniques to help with teaching and learning rare languages. Check them out.

So obviously, I’m a big fan of their work. The question is: how can you and I apply it? Here are a few places I’ve tried:

Teaching (training, workshops, presentations)

So, I had an experience not very long ago where I saw these ideas in action. It just happened that I was delivering a very interactive workshop at XP2013. I asked everyone in the room to help me generate what I like to think of as an idea cloud at the beginning of the workshop. The experience was like this: as soon as you entered the room, I was there saying hello and inviting you to help me add ideas on note cards to a wall. My goal was to convey a feeling of “Come play with me!” Soon we had a large crowd of people all standing in front of a wall adding ideas. I was jumping in and out of the group, collecting ideas, offering new ones, handing out note cards and generally dancing like a madman (it all felt a bit maniacal). I had music playing, people were talking and the room got pretty noisy pretty quickly. They were competing for space at the wall, helping me facilitate, and generally helping to contribute to a wonderful atmosphere of barely controlled chaos. Folks seemed to be pretty deeply engaged. They were showing me ideas I had never seen before, and I even managed to toss a few originals into the mix. We were teaching each other.

I remember turning around at a key moment to talk to the group. I had my back to the wall and I was surrounded by about 40 people all standing about two feet away and looking right at me. Staring into this sea of expectant faces, I had a moment of panic (it was a little intimidating). I put up my hands and almost reflexively said, “OK everybody, let’s sit down.”

Immediately I realized I’d just made a huge mistake.

matador

All at once I could feel the energy drain out of the crowd. There was almost a palpable sense of disappointment as people searched for a chair. I could almost feel the energy in the room go “Poof!” and disappear. It took me another 10 minutes to get everyone back up on their feet and fully engaged again. The rest of the workshop went great, but that moment where everyone sat down made a huge impression on me. I realized that I had created a critical element of aliveness and engagement that felt almost magical (people told me afterward that they thought it was one of the most energizing workshops they had attended). I think I had managed, for a brief time, to create that alive learning experience in a group of people. Referring back to the 5 Rules, perhaps I had a combination of focus, aliveness, and setting (3 of the 5 rules!) working for the group.

Interviewing

I wrote about an experience with interviewing recently in Bob the Naked Agilist. In that interview I introduced a drawing and asked the participants in the interview to help me clothe a hypothetical Agilist with the things that they would need to survive out in the corporate jungle. It swiftly turned into a very engaging and dynamic dialog where we were generating ideas together and asking each other spontaneous questions about the things we thought were important for our work. For me, it felt like the conversation opened up.

Compared to the traditional interview where we all sit around the table in combative postures and quiz each other, this felt like we were collaborating on building something together. The energy was completely different (and honestly, quite refreshing compared to the usual drudgery of an interview). All I did was walk up to a white board and start drawing pictures. Next time, I’m going to get everyone up at that white board drawing too. I want people to experience interviews differently.

Dear God I must be nuts.

Fire Writing

So I managed to use the aliveness, focus and signal rules to improve the interview. Now that I think of it, an interview is a very intense learning experience for everyone. It makes a lot of sense to try to improve them.

Meetings

One of the things that I think we have done particularly well in the Agile community is rethinking the way meetings are run. For instance, I believe that when I’m doing a meeting well, there are rarely any projectors or PPTs. The walls are usually completely covered with sticky notes, diagrams and all in a bewildering array of handwriting. That’s because everyone in the room has been contributing. Chairs are kicked out of the way against the wall. Tables are piled high with collaboration tools: sticky notes, sharpies, and stickers. None of this is particularly new or extraordinary – these are all the attributes of what I have come to expect from any experienced facilitator when they are dealing with an Agile team. It could be a retrospective, or a planning meeting – it really doesn’t matter. Why is this important? Because we have a body of techniques that makes our meetings feel distinctly different from the usual meeting. The experience is manifestly different.

Coaching

Recently I was working with a team and just happened to be observing one of their stand up meetings. As a coach I was watching and waiting to see how the team dynamic would play out. As I stood there quietly, it occurred to me that I could use the 5 rules to help me asses the outward experience of the team as an outsider. I quickly jotted the 5 rules down in my notebook, and then asked myself some questions: Does this meeting feel Alive? Joe over there is bouncing up and down on the balls of his feet over there. There’s a lot of energy pent up there. Either he has to go to the bathroom or he has something he really wants to say. Nobody else is moving. What’s up with that? Are these people alive or in zombie mode?

Then I switched to the next rule: signal. What message is this person trying to send. Is it clear enough that I can understand it as an outsider or is it encoded in jargon. How are others receiving his message? Is he mumbling? Why?

For each rule I discovered a lot of interesting questions that were open for me to ask. After the team finished I pulled them together for a quick huddle and shared the 5 rules model with them. As I did so, I offered a few questions that I felt would offer seed opportunities for further exploration or introspection. With the judicious use of a few funny examples from my own past, I set the hook. What would you change to increase the liveliness of the meeting? How would you change the environment to improve the learning that takes place? What could you do to improve focus?

So the 5 rules served both as a source for assessment as well as a roadmap for improvement.

Where next?

These days I ask myself, does this feel different? Is this the experience I was hoping to create? Sometimes the answer is no. When that happens, I feel like what Willem and Diana have given us in the Five Rules of Accelerated Learning is a set of strategies I can use to create that new experience.


Witnessing Craftsmanship

September 23, 2013

GreenPainter

Recently we hired a painter to do the exterior of our house. At the time I thought we had simply purchased the services of a painter, however I soon discovered that we were getting something more. We were getting a tutorial in the fundamentals of craftsmanship.

It all started with the first day of work. We had contractors working on an addition to the house. They would typically show up around 8 in the morning each day and work until 5. Our painter however, was different. He would show up at 7 AM and work until 7 PM in the evening. This guy had the work ethic of a Clydesdale. Now I’m sure he was pushing himself hard, but it wasn’t like he was griping about the long hours. In fact, he seemed completely focused on one thing – making sure he was doing the best possible job. He wasn’t asking “Am I done yet?” rather he seemed focused on “What more can I do to make this job perfect?” It was obvious that he took a lot of pride and satisfaction in his work. Unlike a lot of the other contractors, he did all of his work alone.

patches

He started with prepping the house for the paint. I figured he would give the siding a quick power wash and then get right to it. Maybe take a day. Instead, he power washed the siding, then he got out the filler and proceeded to methodically fill every crack, nail hole and imperfection he could find. Then he took another day to meticulously sand all of the patches and anywhere there was a hint of an imperfection. Three days and he never even opened a paint can.

Now, I don’t know a damn thing about painting houses. Maybe everybody does it this way, but I have to say I was mighty impressed. Every day he would show up before everyone else, and every day he would work longer than anyone else. He was focused to the point of myopia. And he was a pretty nice guy. Weird.

When he finally got around to putting the paint on the house, the results were spectacular! Lines and borders were crisp. Everything was carefully taped off in advance. Ground cover laid to catch spills. Again, the preparation was immaculate.

Now it’s not that he didn’t make mistakes. He did make mistakes. When he made them, he called them out and knew exactly what to do to fix them. He didn’t try to hide them or avoid them in any way.

OLYMPUS DIGITAL CAMERA

Now it was pretty obvious watching this guy, that he was achieving what we might call a state of flow. He was focused, challenged, pushing himself and in the moment. I remember watching him and feeling envious. To be that confident in your work, and able to get into that zone is absolutely amazing.

It’s certainly not where I live. I’m in meetings all day long. When I’m not in meetings I get interrupted every 5 minutes by people who were waiting to get my time – because I was in all those #$%^& meetings. My experience is not one of flow. I never get the time to focus. I seem to be progressively working myself into a raging case of attention deficit disorder.

Watching this guy I started to get an intuitive feeling for what that mysterious “Craftsmanship” thing might be all about. I wasn’t about to micro manage this guy. I guess I could have stepped in and told him to spend less time on prep. You know, “We don’t need any of that puttying and sanding! Just powerwash it and start laying down some paint! That’s what I’m paying you for! Not for farting around with putty and taping every last corner exactly right.”

To go that route would have been crazy.

No, what I was seeing here was some sort of relationship between craftsmanship and flow. This was a guy who was uncompromising in his drive to excellence. He painted our front door, then let us know that he’d probably over done it. It was Friday afternoon. Sure enough, as the paint dried there were drips and runs. So what does he do? He shows up at 7 AM on Saturday morning and proceeds to sand down the entire door by hand. Then he repaints it all again – perfect this time. We didn’t ask him to. He told us that’s what he needed to do. I was happy to pay for that kind of quality. It was amazing.

So the $64,000 question is, what would that kind of craftsmanship look like in software? Pick a role, any role: Developer or QA? Scrum Master, Product Owner, Project Manager, or just plain old Manager.

I used to work with a developer who delivered absolutely amazing work. You would sit down and discuss the requirements with him and then he would look at you and say, “Give me a couple of days to do some research and then I’ll start writing some code.” And that’s exactly what he would do – he’d spend all day for 3-4 days just reading books and researching the topic and examples of the code he had been asked to write. Think of it as the prep work – understanding the problem, looking for issues, asking questions, researching other approaches. It’s really not a whole lot different from prepping the house for paint. Power washing the walls, sanding, patching, taping and generally preparing for the work to come. Setting things up to go smoothly.

And once this developer finished his prep work he would write the code in record time, complete with unit tests! It was tight, concise, and easy to read. You could tell that he had taken the time to understand the problem deeply. Objects and methods were clearly named and made sense. The whole thing was elegant. And he delivered! Nobody messed with him. You don’t look at a guy like that and say, “Geez, I really need this fast, can you just hammer it out without doing any research.”

Well, to my undying shame, I actually did that. And I got the answer that I deserved,

“No.”

Asking him to It was like asking him to not wash his hands after going to the bathroom. He had found a way of working that delivered quality that excited his customers. He wasn’t about to compromise that just because some project manager wanted it faster.

I worked with a scrum master who would spend hours preparing for a sprint planning meeting. His mantra was that you should spend twice as much time preparing for a meeting as you do actually attending the meeting. His meetings were meticulous. Often times he had done enough work with the stakeholders in advance that the entire meeting was really just a chance to recap the decisions already made and seek final sign off. To him, a successful meeting was the culmination of many hours of prep work. I think of this as the craft of facilitating a good meeting. Ask him to slap it together faster and he would look at you and ask, “Why bother wasting time on a meeting at all if you aren’t willing to do the legwork?”

Good question.

I believe that at some level there is an element of craftsmanship that can be found in most work whether it is manual labor or knowledge work. I think we all would benefit from finding that craft in our day to day. It offers us the opportunity to find flow in our work, to take pride in what we do, and ultimately to delight our customers/stakeholders.


Bob The Naked Agilist

August 25, 2013

IMG_1917

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:

IMG_1918

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:

IMG_1919

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!

IMG_1920

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:

IMG_1921

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

Super_Grover_flying_high

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

rocket-sled-john-paul-stapp

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!


Follow

Get every new post delivered to your Inbox.

Join 522 other followers