I was once working with a peer agile coach and we were discussing the role of the coach within agile teams. His view was that it was as a “soft, encouraging, influencing” role. That at its core agility is about the team. And the team in this sense is…self-directed.

He also emphasized that taking a more direct or prescriptive approach in our coaching would be anathema to good agile practices. That it was draconian and dogmatic.

He was actually a leader of this firms coaching team, so he had tremendous influence over a team of ten or so agile coaches. I was one of them and I sometimes struggled with his view and approach.

Now don’t get me wrong. I honestly get the importance of self-directed teams within agility. I want teams to sort out things on their own. But I also think that we should occasionally provide some direction as coaches instead of always deferring to “it depends”—especially if we’re dealing with brand new teams that don’t have a whole lot of experience. This leads into the whole area of situational coaching, which is where I’m going next.

Shu-Ha-Ri

A fairly common method for expressing team experience in the agile community is the metaphor or model of Shu-Ha-Ri. It comes from Aikido and represents three levels of team experience:

1. SHU – Novice, entry level, newbie
2. HA – Journeyman, mid level, experienced practitioner
3. RI – Master, high level, expert practitioner

The metaphor is useful in expressing the situational coaching involved with agile teams at these various levels. For example, I would expect a coach to be relatively hands-off and simply guiding for a RI-level team.

However, when that same coach encounters a freshly minted, SHU-level team, I would expect them to give the team quite a bit of prescriptive guidance. Also clearly articulating organizational constraints to the team, for example, helping them establish their Definition of Done.

Self Discovery

Many of the CST’s have started to present their CSM classes with minimal to no Powerpoint slides. They’re leveraging a style of training entitled (TFTBOTR), which has been developed by Sharon Bowman. The style is mostly focused on short bursts of discussion followed by hands-on simulation, exercises, or gaming to get the points across.

Of particular interest is the focus by many of our CST’s on gaming, where they want team members to learn on their own. Again, while this is useful for some with this learning style, not everyone has this style. And it also assumes everyone being at a certain level of experience.

I guess the point I’m trying to make is that we all have different levels of experience, different learning styles, and different tolerances for this self-discovery approach to learning. At what point does having an expert coach truly directing or prescribing the next 10 steps of your journey help you more than trial and error discovery on your own? And where is the balance?

I’d argue that you need a balance of both, but there is a tendency in the agile community to lean heavily to the self-discovery and self-direction side of the equation. I want to start challenging that view to a degree.

And are we being “Too Soft”?

A famous Project Management consultant and teacher, , ran a very popular workshop for a number of years. I believe he still runs a variant of it. The title, loosely interpreted was: The Problem with Most Project Managers—Too Soft!

His primary premise in the workshop was that project managers lacked the courage to truly engage their teams for what I would call the “hard bits”. Things like personal performance, estimate integrity, commitment, providing early feedback on issues, asking for help when appropriate, telling the truth to leadership, taking personal risks, etc.

He pointed out that it was easy to go through the tactics of project management, but that real leadership and maturity was driven from a different place—a willingness and a skill to attack virtually any topic or issue that was standing between the project team and success. That there was a tendency for avoidance of topics that were uncomfortable or difficult to face and discuss.

His main point was that within this space of avoidance lied the success or failure of most projects and that successful project managers had to have the hard discussions and lead from the front.

Now most project managers don’t consider themselves too soft. Nor quite frankly, do their teams. But it’s where they’re being soft that counts. And why am I bringing up this story?

Because I think I want to make the same assessment and then challenge many agile coaches as being “too soft”.

What does “Too Soft” look like?

I can’t speak directly for Neil Whitten, so I’ll leave project management alone. However, I can speak for agile coaching. I do believe we’ve generally become too soft as a discipline of agile coaching. There are probably dozens of contributing factors, but I want to share five that come to mind:

1. An unwillingness to “tell” the team what to do—I see this incredibly often with agile coaches. The team directly asks them for help and under all circumstances they decline to directly answer the team. Instead, they fall into a pattern saying: “it depends”, asking questions, playing games / simulations, or telling stories as a means of showing the team the way. I often liken this to a “pull request” and frequently I’ll directly give an answer to the team. At the very least, I’ll give them a few options that I’ve seen work in similar situations and I’ll make a recommendation to them.
2. An unwillingness to step in and say “Stop it”—This is an even harder thing to do at times. For example, estimation is something that many team struggle with. A common pattern is for teams to estimate at too fine a level of granularity. Their hope is that success will surface from the details. But often the reverse is true. That planning at a higher level and sorting through the details as you go is the best strategy. If you encounter a team who is obviously “in the weeds”, will you tell them to get out? Even if you’ve seen this “pattern” a thousand time? I’d say that I would. And I’d like you to consider it as well when you get into similar situations when you know that a team is going to “crash and burn” by using the wrong tactic or practice.
3. A lack of balance in knowing when to say when—Often coaches stay the course in one direction or the other—either they are consistently too hard or too soft. They lack the balance across both of these dimensions. And the teams they coach suffer as a result. I often think that experience comes into play here. Many agile coaches have little experience in their careers; often less than 5 years of agile and 10 years of overall software experience. Much of my coaching depth comes from my experience, and that’s not simply agile experience, but my waterfall history helps immensely as well. Don’t be afraid to leverage ALL of your experience and don’t be afraid to say “I don’t know”, and ask another coach for help.
4. A lack of situational awareness vs. prescriptiveness—I brought up Shu-Ha-Ri intentionally to illustrate the incredible importance of “situational awareness” when it comes to your agile coaching. That when you’re coaching Shu-level teams, you better be prepared to provide them direct guidance and support. I’ve found that wrapping the ceremony of reflection or retrospective with situational coaching is a wonderful way to help guide your team. As they are exploring an issue or a challenge and looking for way to attack it, you can bring up your own stories and advice and get it into play. I also think you can be quite firm here, and yet still let the next steps emerge from the team.
5. A fear of engaging or getting “in the game”—Many formal schools of coaching encourage the coach to stay at a distance. The coach owns the observations, but the coachee, team, or organization owns the action decisions and performance results. There is a fine line between the two. While I honor that view and maintaining some healthy boundaries, I’ve found that being in the game with the team helps to connect your coaching to the reality of the situation. And it often emboldens the coach to be more prescriptive. I think what I’m saying is that the coach having a stance “as a team or organizational member” is healthy and will draw out more situational prescriptiveness.

Wrapping Up

I submitted this topic as a session at the 2014 Agile Conference in Orlando and it was selected. I was very, very excited about that and was looking forward to seeing how others in the community reacted to my ideas here. Unfortunately (or fortunately) I was invited to be a part of the Agile China experience the same week and I declined to present at Agile 2014. I’ll be doing more research and thinking on this topic in 2014 and will submit it again in 2015.

I’m also making an odd request that I hope some of you take on. I’d like someone to respond to this article with a view to what “too hard” looks like in agile coaching. I’d love some examples and general guidance and anti-patterns that you’ve seen in your coaching travels. I guess my point is I’d like to see both sides represented, because I think the truth lies somewhere in between.

Stay agile my friends, and occasionally try to be more prescriptive in your own agile team and organizational coaching.

Bob.