Solving Complex Adaptive Problems with Rubber Ducks
Promoting healthier interactions in Development Teams
This one is about a technique called rubber ducking. There are other names for this technique, and it can be used in many helpful ways. Scrum Teams work on Complex Adaptive problems. Anything that helps should be considered.
Breaking my own duck
On my first encounter with the technique, I was the rubber duck. I am a Scrum Master now, but I was still a developer then. That day, a coder colleague hurriedly wheeled a chair up beside my cubicle.
“Gimme a second, I just need to rubber duck something…”
I was kind of in my own flow, so the best I could muster was a quizzical look..
He hooshed me quiet with a hand and said quickly “don’t worry, don’t worry, you don’t have to do anything, just listen for a minute, I need to talk something through…” I mumbled something about it being ok, but he was already talking again:
“So I’ve got the new business rule hooked into the automated process, but it’s failing, as we know, right?”
I nodded. He had mentioned something about it at the Daily Scrum that morning. Something was taking longer than he thought for some reason.
“So I’ve got the old unit tests working again finally, but now when I try to run my new test, it fails with a ClassCastException in the init method of the base BusinessRule class. I’m mocking every dependency I’m aware of, so I think it might be something to to with the…”
WHACK. He banged the desk.
“THAT’s it! Thanks!”
With that, he wheeled away happily back towards his desk. Ten minutes later, some more loud noises from the same location indicated further progress. I heard the explanation of the technical impediment later, but I was more curious about the technique.
“Rubber ducking? It’s about getting outside of your own head when you’ve been stuck on a problem for a while. Talking it through can unlock the next step sometimes.”
If it looks like coaching, and it quacks like coaching…
I’ve used this technique many times myself since, and not only for debugging code. At times I’ve been the talker and at others I’ve been the ‘rubber duck’. Either way, I estimate that the technique succeeds far more often than it fails.
Particularly when working on technical problems, it is possible to get mired in a quagmire of thought. We may open more than one thread of investigation simultaneously in an attempt to find a resolution, and sometimes these lines of enquiry don’t reach a satisfying conclusion. In complicated contexts like this, it can feel like the problem will never be solved. As humans, we can tie ourselves in knots, multi-task, and find it difficult to take a step back. Problems can appear more complex than they actually are.
Simply taking a moment to rubber duck with a colleague and talk through what you have tried so far can unlock ideas for the next investigations to try.
This type of conversation is an easy way to encourage collaboration on teams. It is also the gentlest of all possible introductions to pair programming.
Coaching is about interacting in ways that can encourage creativity and unlock potential. For this reason, I believe that rubber ducking is a deceptively simple, powerful technique for development teams to self-coach, unlock creativity and remove impediments to progress on complex, adaptive problems.
This technique also stimulates learning. When you can successfully explain a complex problem to someone else, it shows that you really understand it.
Sometimes that understanding is a work in progress, and you need to rehearse the verbalisation to help with your own learning process.
Sometimes just hearing out loud will trigger something in your mind.
Other times your rubber duck colleague will even respond and point out something painfully obvious that you have overlooked up to now.
Is your team familiar with the rubber duck technique? Why not give it a try? At times you’ll hate him, but I’m willing to bet your team will end up loving that stupid duck :)
For more on rubber duck debugging, have a look at this excellent write-up by David Hayes.
