The Agile Architect

Agile Coaching the Wrong Way!

Our Agile Architect shares his blinders and blunders as an agile coach.

• By Mark J. Balbes, Ph.D.
• December 12, 2013

I have a confession to make. Sometimes I can be a horrible agile coach. I'm not talking run-of-the-mill mediocrity, nor am I saying this now to build myself up later. There are times when I'm just wretched.

I attribute this to two reasons:

1. My natural scientific tendency to want to solve problems
2. My inability to distance myself from my own teams

Let's take these in order.

My disease, if we can call it that, strikes when I'm trying to coach a team through their problems, whether it's technical, team dynamics, process or whatever. I get drawn in. I want to help them solve it.  I want to play. But I can't. I shouldn't. I'm the coach. I'm there to guide them through the process of how they can solve their problem. It's not mine!

But, but... I've been creating software for over 20 years. I know lots of answers. I usually have a lot of good ideas for them. I really, really want to tell them what they should do. And then, sometimes, in the heat of the moment, just when I shouldn't, I do!

And that robs the team of their opportunity to own the solution. But so what, right? I mean, they have the solution to their problem. It's probably as good or better than what they would have come up with. I mean, come on, I'm awesome!

Or am I?

When I don't succumb to my disease, I take a far different approach. I won't give any answers. All I do is ask questions. And not leading ones like "Do you think you should do solution x?" Instead, I ask questions about how to characterize the problem, how to look at it in different ways, what kinds of risks are being created, what the goals of a solution should be and how that changes their processes. These are questions designed to make the team think about the various dimensions of the problem. I'll facilitate games that get their creative juices flowing and draw out ideas from team members who otherwise might not participate in an open discussion. Basically, I'll do anything I need to do (other than actually give them the answer) until they are satisfied that they've come to a reasonable conclusion.

So where's my piece of the action? After all, I'm in this personally to satisfy my itch for solving hard problems. What I have to remember, and sometimes forget, is that I've got a different problem to solve. While the team is working on their issue, I have to figure out how to help them without giving them an answer. That's a much tougher nut to crack. It's very rewarding when the team reaches their own conclusion and is excited about their accomplishment.

Distance
It's much easier to be objective when coaching a team that is not your own. The closer you are to the problems the team is trying to solve, the harder it is to be objective.

This doesn't mean that you can't have an agile coach on the team. It's just that the coach shouldn't also be responsible for delivery of the software. On my teams, I try to teach agile practices and be a good agile steward, but when there are tough issues to solve and an agile coach is needed (especially where I want to be part of the conversation) I will ask another coach to come facilitate the discussion.

That is if I'm feeling particularly smart that day.

There was this one day when I wasn't. You see, I'd been getting very frustrated with my team's retrospectives. The retros always consisted of the same few usual suspects talking, with everyone else tuning out. So one retro when our regular facilitator was not available, I decided to facilitate it myself. After all, I'm an experienced coach and facilitator. Other teams tell me how much they enjoy their retros when I facilitate. How bad could it be to do the exact same thing for my own team?

It can be very bad. It can be very, very bad.

The retrospective was a train wreck. Even though I had planned out exercises and games, I could not keep my mouth shut. With my team, I'm too used to being a leading participant in discussions and having the final say, if such a thing is needed.  I could see the retro going south and there wasn't a thing I could do about it. Even though I knew exactly what to do (shut up!), it wasn't happening. Every time one of my team members made a comment I didn't agree with, I was compelled to correct them, disagree with them, override them... Finally, by the Grace of God, time ran out and the meeting was over.

The Other Side of the Coin
Everything I've said so far would lead you to believe that a good agile coach is dispassionate and unconcerned with helping the team find the actual solution to their problem. And that is what the books about agile coaching say. It's the adage about teaching a man to fish instead of giving him a fish.

For my part, I get very frustrated when I see an agile coach who is also very technically knowledgeable withholding information from a team because he is wearing the agile coach's hat. For me, I see a distinction between telling a team the solution they should implement, giving the team different choices for different solutions that they might consider and giving the team factual information that is useful in their decision-making process. I have no problem giving a team factual information that they don't know. I'll often make a point of telling them, "I'm taking off my coach's hat and putting on my technical hat." Factual information could be about technologies they don't know exist, agile best practices or what other teams in our company have done in similar situations. Just because a team needs to own their solution doesn't mean that they have to reinvent the wheel.

I also will ask the team if they've considered different types of solutions, e.g. a process change instead of a technical solution. While this might start down the slippery slope of giving them an answer, it is sometimes necessary to break them out of their own blinders.

So while I chastise myself when I find I'm giving the team an answer, I don't feel bad sharing my experience and knowledge if it helps them find their solution.

Final Thoughts
There are a lot of books that tell you how to do agile coaching the right way. Only your humble Agile Architect would dare to tell you how to do it the wrong way! 

Now that I've told you about some of my shortcomings and faux pas, feel free to share yours in the comments section below.