The Humble “Yo!”

Here are a few cases of “bad luck”:

• The afternoon before release, someone checked in a bunch of changes. They’d been working on their own for a couple weeks, so they had a fair number of changes to make. They didn’t understand how to merge code, so they just copied their version on top. Nobody noticed right away, and other people merged their changes on top of those.
• Two people working together spent a week creating an inappropriate design (with no tests, either!) and applied it all over the place. By the time anybody else got into that area of the system, it was very hard to undo the damage.
• All testing was done in a single shared database. Someone deleted all the stored procedures, and it took an hour and a half to find somebody authorized to restore them.

On XP teams, there’s a “rule”: if you ask for help, you will get it.

If I’m Stuck, Why Should They Suffer?

When you’re stuck, it can be easy to try to rely on your own wits to solve the problem.

One problem is that a problem can take longer than you expect to solve it: you spend an hour, then another, and another.

But a bigger problem concerns the effect on total productivity. Our model might look like this:

We’re stuck, going slow, but at least they’re moving forward.

But that model misses a key point: it’s possible to have negative productivity! Look what can happen in that case–the whole team is actually moving backwards.

But instead of staying in our slump, suppose we interrupt “them”, and they take a few minutes to get us re-started. Then our net  productivity can get back to what we expect:

Stop the Line

One of the lessons from lean manufacturing is their attitude toward stopping the assembly line. In a lean line, workers are expected to stop the line as soon as a problem is found, resolve the problem, figure out why it happened, and put something in place to ensure it doesn’t happen again.

How can this work for software teams? Kent Beck has described a very gentle form: if you need help, or have a problem, or are stuck, raise your hand. This is not a demand for instant attention, but a request for attention when people are done with their current thought. (Others might finish the typing the paragraph they’re working on, but wouldn’t start a new one.)

Furthermore, the raised hand is a request for the full attention of the entire team. Full attention means hands off the keyboard, eyes off the screen, and focusing on the requester. Full attention is very powerful. With the team’s full attention, most any problem will be solved.

What are the consequences of this rule?

• Nobody is stuck unless everybody is.
• Most interruptions are small.
• Knowing you can get help frees you to try things you might be afraid to otherwise.
• People get reminded that they’re worth paying attention to.
• The team demonstrates that they succeed only as a team.
• People don’t resent interruptions as much; they already gave permission for it.

Just like in the manufacturing line, it seems a little paradoxical: the ability to stop everything makes the team faster overall.

Adding a “Yo!”

One team I know added a twist: you’d call out “Yo!” in addition to raising your hand. This makes for a slightly less gentle interruption, but it works too.

People worry about how hard it will be to concentrate in a shared workspace. But the reality is, even in a fairly noisy room, you get very focused on the task you and your partner are doing. Calling “Yo!” is just enough to let people know that the request isn’t a background noise, and gets enough attention that people know to stop what they’re doing.

Asking for Help

Confessing ignorance and asking for help take practice. Many people are used to hiding their ignorance, presenting an omniscient front. It can be scary to move the other way. It’s important that the team treat all requests with the respect they deserve.

So…

Propose a new convention for your team. Getting attention and help when you need them can reduce problems and help you move faster than ever.

[Written June, 2004, by Bill Wake.]