I was running one of my coaching circles the other day and someone brought up the X-wing Coaching Model. To be honest, I had to admit that I didn’t know what that was.
Then they sent me a link, http://agilecoachinginstitute.com/agile-coaching-resources/
and I realized it was the Agile Coaching Competency framework put forth by the Agile Coaching Institute. It’s a model (picture) that speaks to the various capabilities that one should have when approaching agile coaching.
I wanted to share a couple of reactions to the model.
First, Can I Really DO It All?
One of the problems I have with the model, and it’s one of the few, is the implication that a coach needs to have competency/skill in all of the areas. Or to be growing their skills broadly across all of them. And my issue is, I don’t think that’s possible.
For several years, I was heavily involved in running Scrum Alliance Coaching Retreats. I probably attended 5-6 of them over time. And they filled a necessary niche where folks who were in agile coaching roles could gather together and share ideas and challenges.
But the format of the events was focused towards running small projects as Scrum teams. You can read more about that here.
Well, last week I attended my first Agile Coach Camp – US in New York City. It ran from Friday evening to mid-day on Sunday. And it was held at the Spotify offices. It was run as an Open Space.
WOW!
I was writing another blog post about the lack of an agile engagement having a cohesive coaching team and it dawned on me that I’ve never shared what an agile coaching team might look like.
Given that inspiration, I thought I’d spend a few minutes discussing aspects of creating (finding, forming, and building) a great team of coaches for a larger-scale, agile transformation initiative.
Followers
I honestly don’t know where the quote comes from, but I’ve heard that in order for you to become a great leader, you need first to become a great follower. That by following, and putting on the mindset of service, you better understand leadership.
I attended an agile coach’s gathering about a year or more ago. It was a “coaching the coaches” session and it was very valuable. But an aspect of it has stuck with me ever since. One that I’ve mulled over and over and would like to share.
There were a group of coaches in attendance from the same client engagement, a large, multi-billion-dollar organization that had been going Agile for a couple of years.
When they decided to go agile, one of the first things the client did was reach out to an agile coaching firm for help. On the surface, that sounds like a good thing to do. However, the firm was largely staff augmentation focused, so that was their background and comfort zone.
At the end of 2016, Josh and I had published 106 posts on our Meta-Cast agile podcast that we started in January of 2010. So, we've been LIVE for 7 years now.
In that time, we've published on virtually any agile topic you can think of. I thought I'd share our Top 3 podcasts from 2016.
In this segment, we actually review one of our early podcasts that focused on agile testing and then shared some of our updated thoughts and reactions to the topic. It turns out that much remained the same, but there were difference (shifts) in our thinking.
In this segment, we explored the "movement" that is implying that agile is DEAD. We look at the forces behind it, the why if you will. But we also weigh-in on our own thoughts. And if it's not dead, where IS agile now and where is it GOING.
What's interesting in this segment is that Josh shares his direct experience at The Dude implementing agile methods. His focus has been on Scrum, Spotify, and a bit of SAFe. He characterizes it as The Agile Donut. Listen in.
The Meta-Cast is into it's 8'th year. We hope you continue to follow us and that we continue to provide value to the community.
Stay agile our friends!
Bob.
I was inspired for this article by the same titled blog post from Simon Nadav Cohen that you can find here: https://labs.spotify.com/2016/05/13/to-coach-or-not-to-coach/
In the article, Simon speaks to his experience of overusing the “coaching stance” in his agile coaching interactions and showing that more nuance is often required. I wanted to explore it even more from an additional context – that of leadership coaching. But let me start out here…
The 5 Why’s
Are you aware of the 5 Why’s tool? It’s a lean technique for getting to the root cause of a problem or challenge. You keep asking why, five times in fact, in order to “peel the onion” of a problem and get to the root.
I stumbled on a blog by someone I hadn’t heard before. His name is Tanner Wortham and the blog is Spikes & Stories.
Here’s the link to the post: http://www.spikesandstories.com/qualities-of-great-agile-coaches/
In it Tanner explores qualities of great agile coaches with a theme of their biases:
- Bias towards learning
- Bias towards action
- Bias towards innocence
- Bias towards honesty
- Bias towards silence
- Bias towards the team
I loved the premise of the post and feel inspired to extend it a bit. So adding a few additional biases to the mix.
I was sent a request to gather my idea on what Agile Maturity looked like from a column writer. Here’s her request:
Here's my thinking: In 2015, I heard many software pro's talk about "Agile maturity." But you had to listen hard to hear the phrase. Nobody shouted it from the rooftops; it’s not a buzzword, or even a new idea. It was more of a whisper, an aside that came up in the context of other topics: continuous delivery, better business alignment, mobile testing—to name a few. Yet it seems to me that this whisper is crucially important – that a mature Agile practice is the key underpinning for successful software development.
But what exactly does "Agile maturity" mean? It appears to run that gamut from advanced beginner teams flush with their first solid success to those are that doing continuous delivery, with high levels of test automation that entails.
What is your definition? Is your Agile mature? What are you working toward?
I hate to admit it, but I’m a relatively ad-hoc agile coach. I don’t use a lot of frameworks or tools. I mean I have a few that are well used and well worn, but I don’t have a toolbox the size of Montana (that’s big for folks outside of the United States).
I compensate for the tools with my overall experience. I’m coming up on 40 years of overall experience and 25 years of leadership experience in software development, so that helps me quite a bit in my coaching. And I’ve been leveraging agile approaches since the mid-to-late 1990’s.
That being said, I’m aware of this gap and I’m frequently looking for powerful tools to add to my coaching arsenal.
I’ve occasionally shared blog posts related to questions from my good friend Lee Copeland. Lee will occasionally send me an email asking a question related to an article or talk idea that he has. In this case, he asked me about – “bad things that Scrum typically exposes”?
He sent me this list to illustrate the sorts of things he was looking for:
- weak people (who managed to hide),
- time stolen (by people for pet projects), and
- Parkinson's Law (work expands to fill the time allotted).
I thought about it for a couple of days, as I didn’t necessarily resonate with his short list. In fact, my initial reply to Lee was that – Scrum exposes EVERYTHING; so making a list could be a long effort. But upon reflection, I’ve created a “Top 10” Baker’s Dozen of things (challenges, dysfunctions, problems, etc.) that I typically see when organizations transform to Scrum.
It’s not intended to be exhaustive, but I hope you find it thought provoking…
