As an "agile coach" over the past several years, I've seen a lot of different techniques and approaches. I've been impressed with the ability of some coaches to slowly and gently affect change; sustainable, genuine change. And I've been dismayed at the number of coaches who trivialize the complexity of change to check-lists and notions read from books, but never tried.

This series covers some of the (anti-)patterns I've seen among check-list agile coaches.

Drive-By Coaching

As a coach, you've been working with a team for months. You know their day-to-day situation. You've helped them through simple changes and have encouraged them to experiment and learn what actually works for them. Their kanban board has 15 lanes in it, their daily stand-up includes sharing the best food they ate in the past 24 hours, and they change pairs every iteration. There is plenty of room for improvement, but they are doing better than they were 3 months ago and they are learning to learn. Together.

One day, another "coach" is visiting. Maybe it's a big name coach who's written several books. Maybe it's somebody within the company who is on another team that's practicing agile. Maybe, it's your boss. Wherever they came from, however they came to be here, doesn't much matter. They glance around the room, taking in the kanban board. They attend the morning stand up. They then pull the team manager aside and with the absolute best intentions, share their observations and some recommendations.

"Your kanban board has too much detail to it. A good board has three lanes; waiting, working, and done. And your stand-up is all wrong. There are three questions to answer in stand-up; what did you do, what will you do, and what is blocking you. I suggest you make these changes."

So What's the problem?

I mean the coach is clearly right... right? Kanban boards shouldn't have 15 lanes. There are no examples in any book that show that many lanes. And everybody knows how to do a good stand-up.

The problem is that the kanban board had 15 lanes because we were studying flow across every stage in the formal SDLC of the organization, trying to gather data on the most significant problem areas. And the stand-up included food because the team voted to share something personal each day, but they didn't want to get into awkward territory. They wanted to get to know one another better and find something common they could all share.

The visiting coach doesn't have this context. The visiting coach doesn't know why things are "wrong", only knows they are clearly wrong. And most importantly, the visiting coach doesn't have to live with the impact of their advice.

For how often I hear coaches make snide comments about companies that cargo-cult practices, I hear coaches dispense generic, context-free advice; building the very cargo-cults they will later look down their noses at.

The worst of all is the boss who rather than checking with her coaches and ensuring consistent messaging, arrives at random intervals on client site, and dispenses pearls of wisdom. Each time she does this, she leaves her coaches to gingerly manage the discrepancy between what the team is doing and the off-handed, generic, context-free advice given by the boss, who is clearly more experienced or wouldn't be the boss.

Think twice before you dispense "best practice" guidance. Ask a few questions first. Understand why they're doing the things they're doing. And resist the urge to show how much you know about agile when you know so little about their situation. If you don't intend to stick around to see the entire process through, day in and day out, perhaps it's best to defer specific tactical advice and instead encourage them to cultivate an environment of experimentation and learning.