Why Listening and Understanding is more Important than Knowing and Telling

In the age of “he who tweets and annoys” it may seem an odd notion that taking a more restrained and quieter approach should actually be more effective.  We know that servant leadership is a fundamental approach in all agile approaches, but it is a good idea to ask why it works.  Not just for agile, but for teams and organizations in general.

One of the keys to servant leadership is listening and understanding.  I find sometimes, especially at the ramp up stage of agile teams, that some think I’m just not doing enough!  They want me to be “in charge” and to “run things”.   Maybe they’ve been through the kick off I led and didn’t notice how often I deferred to the various teams.  How I let them discover the questions (“Oh – you mean we have to integrate our results?!?”) first rather than me just providing the answers.  How I let them fail at small things so that they learn better to be proactive on the larger things later.

Here’s the thing.  The human brain can only do so many things at once.  If you are thinking about what to say, you are probably not listening so well.  If you are talking, maybe you are not understanding what others are thinking or feeling.   And if you are telling others what to do, they are probably not learning in any deep sense as they set off on their assigned tasks. 

Agile organizations are learning organizations.  We are trying to make the hidden seen.  To make the unknown known.  To reveal the reality of the situation around us so that we have a common understanding among a producing team and its customers and stakeholders so that we make appropriate decisions and get to valuable results faster.  Anything worth doing will be complex enough that no single person (no matter your title!) can know the full reality of it, so freeing up everyone to learn and grow is essential to being agile and productive.  

When we tell people something, we have provided an answer without that person knowing the question.  It may seem that we’ve expedited results when we do this.  But humans don’t work this way.  Our language represents a personal model of the environment around us.  It’s a shortcut.  If we haven’t truly listened to each other before that point, and then coached or mentored to a common understanding, our “command” will mean different things to each person.  There is no way to convey the full meaning without that common understanding.   

So as I sit in the team common area as a scrum master or coach and seem to be “doing nothing”, I am in fact doing quite a lot. I am actively listening to each person. I am actively watching each person’s body language. I am trying to understand the sense of each person and the team as a whole. What the emotions are as well as the facts and opinions. I am assessing their Tuckman index and Shu Ha Ri progress. I know what the Agile values are and what the principles are and what agile methods and frameworks are commonly used in this organization. I can watch for their use in the team. And I’ll give to the team what it needs when they are ready for it. Only then will I say something, probably in the form of a question.

A story is helpful (we coaches collect stories!). As scrum team stories go, there is nothing particularly exciting about this one. But that’s the point. In every day circumstances we have choices to make as to what sort of leader we wish to be.

So a team I am working with is about mid-sprint. The previous evening I had looked at their burn down chart and sprint backlog progress. I had been prompted to do so because two of the developers seemed more on edge than usual. There’s some snippy dialog happening here and there and some glances askance. Maybe things are not going well? Sure enough, I found additional tasks added to stories in the sprint. They’d uncovered problems that were not obvious or expected in earlier story evolution and sprint planning.

There is something I am expecting from this team. This is their tenth sprint together. They should be monitoring themselves and know what to do. I could tell them. I could assert my authority (I’m the scrum master after all!) and show I know more than they do! But I shouldn’t have to and if I do, I’ll never know if they would have figured it out for themselves. I’d be taking their steam away from them. It’s not about me, after all, it’s about them!

Next day, they have their stand up (they are actually sitting down 😉 and I’m just watching and listening. The six of them are going through what they did yesterday and plan to do today. I listen to all of that and it’s fine as far as it goes. It all seems routine so far. Some quick clarifying questions and dialog. But I want to hear about issues and falling behind. Did anyone look at the burn down chart? Someone should be posting it to the board every day. But that hasn’t happened yet today.

The last two to speak are the ones with the issues. But of course that is not so. The team is responsible for everything. So when will they talk about it?

Nothing from the first of the two. I am ready to ask a loaded question (“Is there something you all want to talk about?”) but figure I’ll wait for the last team member. And she walks up and posts the burn down chart and says, “We found a bunch of open issues on story 132 and 134. They won’t get done today. Maybe not even tomorrow. Can we talk after this about adjustments?”

I never did have to say anything. They did the correct things. Even got the product owner involved. But later that morning at a break I congratulated them for being proactive and making the adjustments. They were learning. And it wasn’t from me telling them anything. It was from me listening.

Leave a Reply

Your email address will not be published. Required fields are marked *