Limits of Professional Coaching
I often come across a compelling question: “Why is a Scrum team better served by an Agile consultant rather than a professional coach?” 🤔
Let’s face it: professional coaching has its limits. It often makes the assumption, which in many circumstances is the correct assumption, that the people you’re coaching already understand how to solve the problems they need to solve.
But in reality, that’s not fundamentally the case for almost all organizations and teams I work with.
Why Early Stages Need a Different Approach
Especially in the beginning, if teams cannot continuously create usable working products in a regular cadence, they fundamentally “need to know what they don’t know.”
At this point, an Agile consultant or Agile coach finds themselves more in a teaching or mentoring stance, helping teams to understand what they don’t know. 🚀
Understanding is More Than Skin Deep 🛠
A deep technical understanding doesn’t mean you can code beside a developer or correct a DevOps engineer’s builds.
I mean having a deep technical and philosophical understanding of the processes, practices, tools, and capabilities.
This knowledge lets you grasp what great teams do differently, especially concerning their engineering practices. 🚀
Know Enough to Know Where to Look
Don’t worry. You certainly don’t need to grasp every tool or technique.
You need to know enough to know where to look. With enough experience and foundational understanding, you can incorporate new tools or techniques into your lexicon and capabilities a lot more quickly. 🚀
It’s About Technical Depth
So, in a nutshell, while Scrum itself is not technical, all the practices and tools around making it successful are deeply technical. 🌟
And that’s precisely why I believe a Scrum team is better served by an Agile consultant rather than a professional coach. 🎯
Sharpen Your Skills with Our Agile and Scrum Courses 🌟
Want to delve deeper into the technical aspects that make Scrum and Agile successful?
Our comprehensive range of courses is just what you need. Don’t wait—enrol today!
Oh, that’s a great question. Why is a Scrum team better served by an Agile consultant rather than a professional coach?
I think professional coaching within the context of a specialist task has its limits, right? Professional coaching is great, but it makes the assumption, which in many circumstances is the correct assumption, that the people that you’re coaching already understand how to solve the problems that they need to solve. And that’s just not fundamentally the case for almost all organisations and teams that at least I work with.
Once teams are up to speed and heading in the right direction, then we might want to focus on a more cultural focus. But certainly early on, and certainly if teams aren’t yet able to continuously create usable working product in a regular cadence, they need to know what they don’t know. This means that an Agile consultant or an Agile coach is spending more of their time in a teaching or mentoring stance, where they’re helping those teams understand what they don’t know or perhaps knowing to look where they don’t know.
I mean, that’s the fundamental problem with having an Agile coach that doesn’t have a deep technical understanding of the work that is underway. And by technical understanding, I don’t mean that they can rock up next to the developer and code and then go sit next to the DevOps guy and point out where he’s doing his builds wrong. That’s not what I mean. I mean a deep technical and philosophical understanding of the processes, practices, tools, capabilities, the direction, the things that great teams do out in the world that other teams don’t, that are to do with their engineering practices.
If we’re talking about a software team, you need to be able to understand what DevOps is, what the components that make up DevOps are, why DevOps is successful, how do you convince a team that they should be doing some of those things, how do you have conversations with teams about continuous delivery if they’re not doing it, and perhaps the teams say, “Oh, we can’t do that here.”
How do you have those conversations, allay those fears within the organisation to enable that for those teams, so that those teams are then able to make that choice? Now they understand that it’s valuable; they can’t just make the choice. You need to help out with the organisation, help convince people that this is the right direction.
And that’s even before you’ve tackled any of those ideas around how people are feeling happy, being safe. They need to be able to do their job as well. So I feel like for Agile consulting or even Agile coaching, the vast majority of the work that they do, that they focus on, is around these technical things.
Scrum itself is not technical; it’s just a bit of knowledge that you learn. All of the practices and tools around making it successful are deeply technical. Are you able to sit with a group of product owners or product management and help them understand impact mapping and how impact mapping can help them, and help coach them in doing that technical task, which is creating the impact map? Those are all things that I would expect an Agile coach/consultant to be able to do.
Now, I’ve named some specific things, like impact mapping. You definitely don’t have to know them all, right? Because there’s hundreds of thousands of these things. But you need to know two things: you need to know enough to know where to look. That’s the first part. If you’ve got enough experience and you know where different tools and techniques have helped in the past, you can then go read up on that tool and technique. Because you already understand all of the foundational concepts and constructs, you’re able to bring that into your lexicon, your capability, a lot more quickly, and then engage with the team and help them or a group of people and help them figure out how to actually do that particular thing.
It can be a learning opportunity for you as well. Deep technical expertise in the fundamental principles of Agile and Lean and DevOps doesn’t mean you know how to do all of the things; it means you have the tools and skills to be able to learn and communicate all of those things, regardless of the environment that you’re dropped into.
Thanks for watching the video! If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.
