How 15 minutes or a rubber duck can help you solve any problem without interrupting your colleagues

Being interrupted sucks. Research has showed that when a knowledge worker gets interrupted, it takes them on average 23 minutes to get back into the task they were working on.

Still, most of us hold the collocated team as the ideal for agile software development. Being able to easily talk to each other is great for coordinating the work, solving problems and jelling as a team.

So is there any way to reduce those costly disruptions while not preventing the valuable communication? As so often, it is all about striking the right balance and I’ve recently come across two rules I think may be of some help.

First, we’ve got the 15 Minute Rule:

If you’re stuck on a problem, take a solid 15 minutes to bash your brain against it in whatever manner you see fit. However, if you still don’t have an answer after 15 minutes, you must ask someone. *

Before you interrupt someone else, you must make an honest attempt to solve the problem yourself. Respect your colleagues time and flow and don’t shout across the desk for a quick solution at every little hurdle you come across. However, you do have a job to do and spending too much time on something that someone else would be able to answer is also an expensive waste of company time.

Next up, the Rubber Duck Rule:

Don’t ask anyone for help unless you’ve asked the rubber duck first.” **

Yes, a rubber duck. This may seem like a rather silly and slightly embarrassing rule – why would you talk to a toy? – but it actually makes complete sense. Just think of all the times you’ve been explaining a problem to someone, only to find that you realise what the answer is, before they get a chance to say anything. Now, replace the person with a rubber duck and you might well get the same result without interrupting someone else. Or, if the duck is unable to give you the answer, you’ve at least worked out how to formulate the problem so that when you do ask someone for help, you can get to the point.

So, there you go. Apply either of these rules, and chances are a few disruptions go away.

Worth a shot, I think!

* You Must Try, and then You Must Ask by Matt Ringel

** Rubber Duck Debugging was introduced in The Pragmatic Programmer by Andrew Hunt and David Thomas.