What is Agile Coaching
In celebration of International Coaching Week 2020, I thought it would be helpful to dive into some topics around coaching. To start I thought it would be good to talk about Agile Coaching to help people understand this role. I think a lot of people don’t fully understand what Agile Coaching is or how an Agile Coach can help them, their team, or their organization. I’ve also heard people who are “Agile Coaches” say things like “they don’t want a coach, they want a trainer” or “they’re not asking for coaching, they’re asking for facilitation”, which I think is really doing a disservice to the role. I hope after reading this article you have a better understanding of Agile Coaching.
If you search for “what does an agile coach do” you’ll find a lot of articles, and a lot of models and diagrams about the skills or knowledge or abilities of agile coaching. They are mostly the same – some break things into smaller chunks, some talk about skillsets the coach should have, and some maintain simplicity while hitting a lot of the key points. It’s clear that there are a lot of commonalities, yet many organizations develop their own model of what they think this should look like.
When I think about how I would describe and break down the Agile Coach position (and in reflecting on the various models out there) I see the following as the sort of “big categories” of ideas –
An Agile Coach is a Lean, Agile, DevOps leader and practitioner
Who brings themselves and role-models behavior
And encourages others to improve how they work through:
Doing, Telling, Consulting, Counselling, and Advising
Teaching and Training
Mentoring
Facilitating and
Professional Coaching
By understanding people.
Let’s dive a little deeper and unpack each of these concepts.
An Agile Coach is a Lean, Agile, DevOps leader and practitioner
I believe pretty strongly that if you’re an Agile Coach, just knowing Agile, or Scrum, or how to set up a Kanban board is not enough. An Agile Coach should be leading the way in growing knowledge and understanding about Lean, Agile, and DevOps concepts – specifically focusing on values and principles, and then looking at practices and tools. Since Agile came out of Lean, and DevOps is a direct successor to Lean – and the prevalence of Lean Software Development an the widespread (mis-) use of Kanban boards – an Agile Coach should first and foremost be growing their expertise in these topics and sharing what they learn to help grow the people around them.
Being a leader in these spaces can mean different things for different coaches. Some coaches were developers or testers in a previous life and bring extensive technical expertise and mastery to the table, and may focus more on those practices. Some coaches are experts in transformation and bring experience and mastery in the space of change management, driving organizational change, and spreading messages across an organization. Other coaches may be business experts, with a heavy focus on identifying business value, taking ideas and moving them through to fruition, or improving processes around how the business actually completes work. Personally, I’m a generalist and have a lot of range, so I dabble in all of these areas. Regardless of a coach’s focus and background and expertise, it should be reflected in how they act as a leader in the space.
However, learning and sharing is not enough. An Agile Coach must demonstrate they practice what they preach! This may be in their own personal lives, whether it’s managing daily and weekly responsibilities, tracking projects, planning vacations, or setting up home-schooling curriculum. An Agile Coach should also experiment with new tools and techniques on themselves before subjecting the team to them – maybe that new idea intake and refinement process will work great for your teams, test it out on a problem you’re solving in your own life. This gives an agile coach a lot more credibility with a development team, when you can say “I’ve tried this, and I really liked it, and here’s why, and what I got out of it – I think you could get something too, I’d like to experiment and see” – the team will be more receptive to something you do yourself. The more you fall into the “do what I say and not what I do” you weaken your relationship and will likely lose influence over time.
An Agile Coach brings themselves and role-models behavior
Being the Lean, Agile, and DevOps expert is really just the start for an Agile Coach. Since an Agile Coach encourages teamwork, encourages the team to learn about and understand one another, to respect people for who they are, to encourage daring behavior and leadership at all levels – agile coaches need to bring this to the table as well.
Bringing yourself is about being who you are, talking about what you’re passionate about. Sometimes it means making mistakes, sometimes it means saying something stupid, or being embarrassed. But that’s courage, and it shows that we’re not just about doing everything by the book perfect – we’re learning and growing and exploring, and our backgrounds and histories impact that. We can uncover new ways of working when we bring ourselves, because we each have a unique perspective, understanding, and behaviors.
So agile coaches role-model the behavior of bringing themselves, but also role-model other behaviors as well. Having the courage to speak up, to ask stupid questions, to have crucial (or fierce) conversations and practice radical candor, to challenge each other, to criticize ideas (but not the people) to voice assumptions, leadership behaviors, and more. The list is really never-ending. And this role-modeling includes what I talked about above where an agile coach should be practicing (to some extent at least) the ways of working they are preaching to the teams they work with.
How an Agile Coach works with teams
Doing, Telling, Consulting, Counselling, and Advising
Agile Coaching is a strange job as one of the big goals is to help the teams figure out the best way of working, and help them to get work done fast, safe, happy – but the agile coach should in most cases not be doing the work themselves for the team. That’s where this bucket comes in – I’ll be honest I’m not exactly sure what to call it because there are so many degrees of this, so I’d like to look at it through the lens of a Management 3.0 tool called Delegation Cards (or Poker), which is a tool to help managers and teams understand how decisions should be made.
Delegation Cards have 7 levels that you move through, numbered 1 through 7. On the “left” side at 1 you have “Tell” where the manager is telling their directs exactly what and how to get the work done. On the far “right” side at 7 you have “Delegate” which is basically exactly the opposite – the team members have fully authority over the decision, and the manager isn’t involved. In the very middle at a 4 you have “Agree” which means the manager and team members have equal decision-making power and need to come to a decision together. As you can imagine levels 2 (Sell) and 3 (Consult) are various levels where the manager ultimately has decision making power, but is either convincing or getting input from the team – and levels 5 (Advise) and 6 (Inquire) is exactly the opposite, ultimately it’s the teams decision but they need to get input or sell the decision to the manager.
When we look at it through that lens, we can see that the Agile Coach wants to generally be closer to a 7, than to a 1 on that scale. With that in mind, here’s how I would ‘point’ and describe the categories I mentioned above:
DOING (0) - this may need to happen in some organizations, but that means the Agile Coach is fully responsible for the idea, plan, approach, and outcome – the team doesn’t really get involved, and they may not learn or be empowered by a coach who does it all for them. Sometimes doing up front may be good to set the teams expectations, or as a way of teaching them, but in general this should be avoided.
TELLING (1) – Just like doing, sometimes an Agile Coach does need to tell the team what to do to help them, but this can quickly devolve into the coach always telling the team what to do (just like a bad manager who tells the team how to get their work done). This can disempower the team, it can make them less confident or reduce courage to speak up, it can lead the team to falling back on whatever the coach tells them – and not think about how they can best get the work done. This one can be risky because the team may think “the coach knows best, they can tell us what to do” without realizing and embodying the idea that they are closest to the work, they are the best to figure out and uncover new improved ways of working.
COUNSELLING (2) – There are many ways to interpret ‘counselling’ but for our purposes I’m going to equate it to “selling” from the M3.0 model. Counselling by definition is providing advice to someone, but in my experience most of the time advice is being given by an Agile Coach they are essentially trying to sell the idea or advice to the recipient. Again, this isn’t necessarily a bad thing – someone who has tried a few things and doesn’t know what to do next, or doesn’t know how to improve things that aren’t working – could be a prime candidate for some counselling. Ideally however the coach isn’t selling ideas, and mentoring can be a good alternative to this type of advice giving. Agile Coaches want to get to a point where team members are coming up with ideas and deciding what to do on their own – sometimes they may need help in generating ideas, or may need example of things that have worked before – but we want coaches to get out of trying to advise or convince people to do something.
CONSULTING (3) – The concept of consulting gets us closer to where we want to be, the biggest problem is that consulting can often mean it is still the Agile Coaches decision about what to do when, but that they at least took the idea to the team and got some input from them before the plan goes into action. Like all of the previous ones, sometimes this is needed and necessary, but again creates that potential risk the team will feel disempowered or defer decision making to the coach. At least in this case the team’s input is being considered and hopefully has a big impact on the final decision so consulting may be less disempowering than some of the previous ones, but it still holds that risk.
ADVISING (5) – Lastly is the idea of advising. In this case the team is ultimately the ones who will be making a decision, but the Agile Coach is providing some input and potentially encouraging the team to adjust the plan. When we’re in this category we’re really moving more towards the team making and owning their own decisions. While the risks are again reduced at this level, there is the potential for this to be abused by the Agile Coach or the team. On the coaches’ side they could come into an advising situation very aggressively and say that won’t work, do it this other way. That would be pretty heavy handed. There is also the potential for the team to come up with a half-baked idea and bring it to the Agile Coach with the hope to really get the Coach to fix the idea and tell them exactly what they should do – this may seem like advising, but is really an anti-pattern to success.
Teaching and Training
A very common stance for an Agile Coach is that of a teacher or a trainer. This may be for developing organization wide training to introduce individuals and teams to Agile, Lean, DevOps, Scrum, Kanban, etc., and ensure all new hires are on the same page. This training may be refreshers for teams that need to go back to basics, or to add or enhance additional skills. It could be on specific and detailed topics like how to manage a backlog, split user stories, manage conflict, deal with bugs and technical debt, have conversations, or other practices the team wants or needs to enhance how they work. I think the idea of teaching and training is pretty straight forward, and the sky really is the limit for what topics or areas could have training opportunities.
Mentoring
Mentoring is an interesting stance that, while generally easy to understand, has some specific nuance that people often miss. Mentoring is the idea of using past experience to give a person or teams ideas about how to approach or solve a problem. It may be things the coach has personally experienced, or in working with other teams and coaches may be things that have been shared with the coach. Fundamentally mentoring is saying “here’s how I’ve solved this problem before, how I’ve seen this problem solved, what I’ve tried before that didn’t work, or what I’ve heard from others about things that have or haven’t worked.”
One caveat about mentoring as a coach is to always add the qualifier that just because something worked for another team, in another situation, under certain and similar circumstances, does not guarantee it will work for you, or that it’s the right or best thing to do. Mentoring can help uncover and share ideas, but every team, every individual is different, as are companies and teams – so that means it may be a starting point, but is not the same as saying “you should do it this way.”
Facilitating
Facilitation is an interesting stance and an area I think is really important, but again has some important aspects that many people misunderstand. I think we’ve all been in poorly facilitated meetings that seem to jump from topic to topic, and at the end nothing was really decided and it feels like time was wasted. A facilitator is there to help create the best space for a group to come to better decisions more easily than they could if they were on their own. If someone has a stake in the decision that is made, if they care about the specific outcome that comes out of the meeting, they really are a participant and not truly in the role of a facilitator. So as an Agile Coach in the facilitator role it’s important to keep that in mind – it’s not necessarily about the specific decision the team makes, but helping them get to where they’ve decided something. There are tons of tools, techniques, and advice out there on improving your facilitation approach – and it sure feels good to see teams have greater success as a direct result of good facilitation!
Professional Coaching
Of all the stances Professional Coaching is probably the least understood, and for a lot of people the most complex. I’m going to give a quick explanation here, but this will likely spawn an article of its own just on the topic of professional coaching.
Professional Coaching is a partnership between a coach and client, where the client’s needs and desires are the focus of the interaction. It is intended to be creative and thought-provoking, where a coach believes the client is an expert on themselves, their life, and work and helps the client to unlock, uncover, or unpack the information inside of them. A professional coach works to understand and clarify what the client hopes to accomplish, helps with self-discovery (often through the use of questions), encourages the client to come up with solutions and strategies for moving forward, and helps to hold the client accountable and responsible.
I think this gets the basics across clearly, but there is much deeper to go, and I think it will need to be the topic of a future article.
Agile Coaches Understand People
The last major trait of Agile Coaches is that they seek to understand people. How humans work, how we think, how we solve problems, how we respond to change, how we work together. Behavioral economics and psychology are usually areas of interest for a lot of agile coaches, and if you’ve been exposed to these areas you known the information is broad and deep. At the heard heart I think we can identify 3 major areas of understanding people that Agile Coaches tend to focus:
Encourage Change / Respond to Resistance to Change - coaches need to understand how humans respond to and feel about change so they can help people feel comfortable with things changing, and also feel like they have ownership. Dealing with resistance to change and finding ways to overcome is also an area that comes up regularly, especially as it relates to “Agile/Digital Transformation”
Manage conflict – coaches need to understand conflict between team members, leadership, and more. Managing conflict may mean bringing people together and acting as a facilitator or coach to navigate through the conflict. It definitely means teaching teams, individuals, managers, executives, and people all throughout the organization to understand conflict, and how to have (and not shy away from) healthy conflict.
Help with collaboration – Coaches must also help with collaboration. Whether that means taking a more active role in bringing people together to collaborate, teaching people how to collaborate, introducing tools and techniques, providing opportunities to collaborate, or simply encouraging and empowering collaboration across the entire organization. This may also be asking questions about why collaboration isn’t happening, or providing a coaching stance to help individuals see the value and importance of collaborating on their own. Either way an agile coach needs to understand how people work together to help them improve and get the best outcomes.
Coaching Anti-Patterns
Before ending I think it’s important to cover at a high level some common coaching anti-patterns. For those unfamiliar in software development a “pattern” is a leading practice, something that tends to work well for most people, and an “anti-pattern” is something that people often do, something you tend to see, that doesn’t work very well or moves us away from where we are trying to go.
Big Change All At Once – the first common anti-pattern is an Agile Coach coming in and trying to make big change everywhere all at once. Uprooting everything that has been done up to this point, and replacing it with something else. The biggest problems with this anti-pattern include making people feel like nothing they were doing before was good (disempowering), or overwhelming people with change which can lead to more resistance and a harder road to get where you’re trying to go. I typically try to make small sustainable changes (with wins!) to build momentum and succeed over time instead of pushing everything all at once.
“Doing” Agile, but not Thinking or Being Agile – You see this a lot in companies that push Scrum – bring someone in, teach them the ceremonies, and roles, and how to story point and let them run with it. Teams starting DOING all the stuff, but nothing changes, nothing gets better. That’s because nobody learned how to change their way of thinking and being to match – they just got a set of rules and instructions to follow without really understanding the why or where we’re going with something. I generally focus more on values and principles to help try to overcome this anti-pattern.
Drive-by coaching – All these anti-patterns are peeves of mine, and this one especially. Drive by coaching is this idea that a coach can pop in, not really know what’s going on, and then make suggestions or tell the team what to do. This one really rubs me the wrong way – the same way that if a new team manager come in and start changing things before they understood the situation the team won’t appreciate it – a drive by coach is going to run into issues with buy in, understanding, may point the team down the wrong path, and biggest of all isn’t establishing or building any sort of relationship with the team. This can also be hugely disempowering if the team has an idea, a coach comes in without fully understanding the context and says it’s a bad idea, and leaves.
Acting like a manager or project manager – Managers come from a place of authority, and the relationship with team members is not the same as it is between peers or others. Project Managers are there to manage a project, not the people, and are heavily focused on getting things done. As an Agile Coach there is no automatic authority in the role, the team doesn’t have to listen to you, an agile coach should gain ‘authority’ through influence and building strong relationships. To that same end an Agile Coach isn’t focused on ‘ensuring the project gets out the door on time with all requested features” – that’s a secondary (or even tertiary) objective to helping the team to work well together, and to find a sustainable pace. A coach should come from a place of curiosity and problem solving. As soon as a coach starts telling the team who should do what work, or how they should work, or dresses them down for not hitting a milestone or objective you know they’re in this anti-pattern.
How can an agile coach help you?
An agile coach can help you in many different ways depending on where you are right now, and what your needs are at any particular time. If you have Agile Coaches in your organization, I’d encourage you to set up some time with them to talk about some challenges you are struggling to solve and see if you can work together to find a way to help overcome. It could be through formal training or workshops. Maybe a coach can help facilitate your next team planning or other meeting. Maybe you can create a coaching agreement and they can help you uncover the solutions inside yourself. Or maybe they have seen the problem before and can share how other people have solved it to help you get over the hump.
Conclusion
Hopefully this article has helped you to understand what an Agile Coach is, does, and how they can help you better. As you can see it’s not completely cut and dry, and Agile Coaches have a lot of things they need to be able to do. Some coaches do focus their expertise in one or a few areas, others are more broad generalists. Either way by contacting a coach and sharing your problems you open a door to many potential solutions.
Coaches are here for you! We want to help people learn, do better, and be better.
If you’re interested in learning more about coaching, or would like to engage in coaching, feel free to contact me at Edward@agile-ideation.com.