The Team Really Does Know Best

“Take it to the team” is a refrain in Lyssa Adkins’ Coaching Agile Teams for good reason.  Sure, there is the clear idea that a bunch of heads are better than one, especially when those heads engage in collaborative discussion to synthesize whole-is-greater-than-the-sum-of-its-parts ideas.  But what’s hit me even faster in my early experiments of applying “take it to the team” is just how off the mark my imagined solutions are.  For context: I am no slouch as a problem-solver; I’ve gotten far on my skills in that area.  But the complexity of these problems demands far more than a single brain can achieve in isolation.

Here’s a typical scenario.  Sitting at a retro, I listen to the team discussing a problem, and a solution leaps into my mind.  I start asking the team questions, trying to lead them to my solution.  (More on the foolhardiness of leading questions below.)  More often than not, within two or three questions, I am surprised to find that the very premises on which I based my solution were faulty.  I was solving the wrong problem.  If I had spoken up when I had the urge to (i.e., almost immediately upon hearing the first statement of the problem), I’d have squashed any chance at uncovering the real nuance of the problem, and I’d have pushed a bewildered team to accept a poorly fit solution.

Again, it’s not that I’m a dunce when it comes to problem-solving.  Or maybe I am.  It doesn’t matter.  What matters is that there is no substitute for a proper collaborative discussion amongst team members to suss out the true intricacies of a problem, let alone for coming up with a possible solution.  It is also striking how quickly this happens.  Sure, I’ve got years to learn more deftly how to help the team find their way, but just taking a simple step back has yielded tremendous fruit.

One other note, regarding leading questions.  Trying to get the team to say what you already have in your head is an amateur habit that I am trying to kick.  It’s transparent, somewhat insulting, and an ineffective substitute for actually helping them untangle a problem.  Why did I get into it?  Because I knew that I didn’t want to just give them the answer, but I didn’t know how to proceed otherwise.  The up side is that the question-asking format kept me from trampling the team in the first place and then allowed me to hear just how far off I was.

Things Take Care of Themselves

I started my practice of Agile coaching by bringing a notebook (one per team) to all team events. I jotted down anything that I otherwise might have spoken up about. The first thing I learned was that things I noted normally got fixed without me saying a word, minutes or days later. They sometimes evaporated into non-issues. Other times, the team noticed the issue and self-corrected. Had I spoken up instead of taking a note, I would have either made an issue out of nothing, or I would have taken away from the team the chance to solve it themselves. Worse, I would have reinforced my position as unnecessary intermediary.

Writing things down allowed me to relax in the knowledge that the observation would not be lost, but also allowed me to look back and see which problems I was wise not to pounce on.

Getting Started

Recently, I shifted my focus to Agile coaching.  I have always done bits of this in my role as Project Manager at our company (we’re a scrum shop), but this is a fundamental shift in my primary responsibility.

I kicked things off by reading Lyssa Adkins’ excellent Coaching Agile Teams.  One major impression it made was the idea that one is never truly finished learning how to be an Agile coach.  Indeed, that’s part of the draw.  It suggested a path that reminded me a little of my (admittedly minimal) forays into sitting meditation: not only would I learn things I expected to learn, even my understanding of what I did not know would shift.

This multi-layered continuous learning is already coming to be, and I am regretting not starting this blog earlier to capture it.  Going to add a couple of posts to try to capture those.