So there we are on vacation at the water park. Life is good – the kids are playing and there are lifeguards are everywhere. The guards are pacing the sides of the pool, whistles at their lips and their heads are swiveling back and forth like deranged bobble head dolls. My wife pointed out that they had a curious ritual around the process of relieving the on-duty guard with the next lifeguard to go on. It went something like this:
The new lifeguard approaches the one on-duty (currently pacing relentlessly back and forth) and greets him/her. They start a dialog and now they are both pacing the edge of the pool, side-by-side.
The on-duty guard carries on the dialog while pointing with one arm at various locations around the pool. The second lifeguard mirrors the first, pointing everywhere that the first guard does without exception.
They continue this action: pacing together in lock step, talking about what they are seeing, and pointing it out to each other for about 15-30 seconds. Then the original on-duty guard lowers his/her arm, says a polite farewell, and heads off for their break – or whatever it is that lifeguards do in their off time. The new lifeguard is now fully oriented and pacing about just like their predecessor.
It really is a remarkable passing of the baton. The routine is very disciplined. They do it the same way every single time – no exceptions. Now, I don’t know anything about how lifeguards work, I imagine this is a well known practice that has been around since the beginning of time. However, it did get my process geek aroused! Fortunately for the lifeguards, I was too busy making sure my own children didn’t drown to hassle them with idiotic questions about how they do their work. However, I was intrigued.
Here is what I was thinking: Where are the hand-offs in my work, and do I manage them as well as the lifeguards do? It seems there are a couple of places where there are some interesting opportunities for improving hand-offs:
Pair programming – In general, the teams that I work with do pairing in limited sessions: anywhere from 1 hour to 3 hours is common. But as far as I know, the sessions are treated as fairly atomic. When we are done we are done, we don’t hand off the work. What if we did? What if there was a new developer who merged into the pairing session the same way that the lifeguards did and then one of the existing developers dropped out? Could we sustain the development pace better?
Coaching – I’ve been in coaching engagements where we are facilitating a marathon brainstorming session with multiple coaches. What would it be like to use those lifeguard style hand-offs instead of the “everybody in the pool” approach that I have used so often in the past? Would coaching be more effective if there were a pairing with explicit hand-offs? I imagine there are people who do this already – I’d like to learn more.
Of course a change like this would have to have some sort of payoff. One would hope that the customers would get some sort of value from developers smoothing out the hand-off of work. If nothing else, I’m sure it would make some interesting experiments for an intrepid team.
Finally, we just might find that there really is no application for these kinds of hand-offs in our work at all. Perhaps the work is just too different. Watching for drowning children is dramatically different than software development – mostly. Perhaps the point of this little essay should be that we need to keep looking. I remember when Arlo Belshee gave his acceptance speech for the Gordon Pask award. He said that we always need to be restlessly seeking how other disciplines do their work. He maintained that there is a wealth of great things we can learn from what other jobs might cast off. So keep an eye on those lifeguards, there might be something really cool we can learn from them – in fact I’m quite sure of it.