Agile coaches often use a “hands-off” descriptive approach when coaching teams. The question is if such a coaching approach is always the best solution when teams are adopting agile? Would there be situations where prescriptive “hands-on” coaching could be more effective? How could you do it?
Robert Galen wrote the blog post what the world needs is-more prescriptive agile coaches in which he challenges the what he calls “soft, encouraging, influencing” coaching approach that is most often used by agile coaches:
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.
He uses the Shu-Ha-Ri metaphor to explain that different teams can have a need for different kinds of coaching:
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.
Bob mentions five factors that you can use to recognize if your agile coaching style may have become too soft:
- An unwillingness to “tell” the team what to do
- An unwillingness to step in and say “Stop it”
- A lack of balance in knowing when to say when
- A lack of situational awareness vs. prescriptiveness
- A fear of engaging or getting “in the game”
In the blog post what is scrum-? … really Niklas Björnerstedt shares his thoughts on what defines Scrum. According to him its prescriptive nature is what makes Scrum popular. But applying Scrum prescriptively can be the wrong approach in some situations:
There are many really good Scrum gurus out there but also large numbers of dogmatic and quasi religious ones. If your context does not fit Scrum their answer is invariably: change your environment so that it works with Scrum. This can be great advice if the thing you are changing is something that is holding you down. It is terrible advice if the thing you are trying to change is part of what makes you competitive.
In the blog post Scrum is dead Andrew Kallman & Ted Kallman described when coaches should be using an “hands-on” style of coaching and when to change to a “hands-off” approach:
Each individual will go through a similar process, at the personal level, on their journey to becoming ”Agile.” Until a person gets to the ”Aha!” moment, they will need additional hands-on coaching, mentoring and support. But from the moment they ”get it,” really get it, then they can become an effective member of the team and the coach/mentor can be more ”hands-off” in their approach with the team member.
The same thing applies to teams. As shared above, 58% of the teams doing Agile are to the left the ”Aha!” line. They are not high-performing by any reasonable, business-value metric. They are either just going through the motions or outright failing. Those teams are going to need a more prescriptive approach to Agile (i.e. hands-on coaching/mentoring) on their journey to the ”Aha!” The 42% of the teams that are succeeding are on the right of the ”Aha!” line above and can be led, coached and mentored in a more hands-off approach (i.e. allowed to self-organize, self-govern, etc.).
Mike Carey wrote a blog post on descriptive versus prescriptive in which he explores how to deploy agile frameworks in a non-prescriptive way. He explains why teams may expect a coach to give direction when adopting agile:
Pure Agilists have always pushed for a more "hands-off" approach. It's interesting to me how married some of agilists become to a certain methodology - conversations with these people usually boil down to "you should let people do whatever they want, but if you're a good coach and they really get the principles then they're most likely going to go with my favorite methodology.(…) The problem is, they've got a point about the coaching. You can't leave teams all to themselves; you have to support them somehow. I'm not saying all Agile teams need a dedicated Agile Coach, but they need the resources necessary to ensure the direction in which they adapt is in accordance with Agile principles and the environment that will support them when (not if) they fail.
His suggestion to agile coaches for giving direction in a non-prescriptive way is to “change the way you say what you're trying to say”:
Make it clear why you recommend certain practices, when they're relevant and highly likely to improve results, and when it might make sense to try something else. You're still going to lay out the recommended practices, but you'll be taking a descriptive approach to explaining them rather than a prescriptive approach.
