The 6 Misconceptions of Agile Coaching & How to Overcome Them
Agile coaching is in a muddle. This post is an attempt to de-muddle the role and offer further learning for those who want to progress on their agile journey into the world of coaching or to better define the role they are currently in.
Agile coaching is not well understood, even by coaches.
I think the role is in a muddle because of these 6 misconceptions that confuse and dilute the power of agile adoption.
1. A Scrum Master is not a Coach
The role of ‘Agile Coach’ has become a ubiquitous catch-all for anyone doing anything with agile outside of the role of Scrum Master. However, the Scrum Master role, according to the Scrum guide, is also a coaching role. The Scrum Master and Agile Coach both can play a professional coaching role.
2. All Agile Coaches know how to Coach
Most Scrum Masters and Agile Coaches have little experience in actual coaching and far more in mentoring and training.
The word ‘Coach’ became popular through Lyssa Adkins’ work and ‘Coaching Agile Teams’ which Lyssa wrote in 2010. Lyssa is quite clear on the definition of coaching and also defines the other skills that an Agile practitioner needs.
- Good knowledge of the Agile practices
- Professional Coaching
And at least one mastery in either:
- or Transformation
Reference at end
You can see that Professional Coaching is just one part of the role.
I am going to use the role title of Agile Practitioner for anyone who specialises in helping others to adopt agile for some underlying business purpose.
Agile practitioners don’t do agile. They help others to solve complex problems using their knowledge of agile / lean, facilitation, training, mentoring, and professional coaching skills.
Professional Coaching is a whole field of expertise. Many Agile Practitioners have now become qualified in Professional Coaching. Unfortunately, many who hold the role of ‘Agile Coach’, do not know what real coaching is, and what the difference is between mentoring and coaching. This is a fundamentally important reason why Agile adoption is less effective in our organisations today. Professional Coaching is the bridge to allow people to change their behaviours. People over process.
A key element of working with people is emotional intelligence and the ability to grow this ability in others. One must first work on oneself in order to help others. In my opinion, many coaches have not yet done this work. Little has changed it seems since Ben Linders aggregated the same comments in 2012.
Coaching is a set of techniques and practices designed to help the coachee find the answers to their challenges themselves. It has the underlying premise that the coachee already knows the answer. Mentoring, however, assumes that the mentor knows more than the mentee and is there to impart wisdom, experience, and knowledge in order for the mentee to succeed.
Both have their place, but almost of all of the ‘agile coaching’ that I have seen, is actually ‘agile mentoring’.
This is a real problem.
When individuals do not believe all of the 3 mindset beliefs, as defined in the Agile Mindset, then the managers and leaders will not demonstrate the right behaviours. Consequently, implementing the processes, practices and tools will either:
- not work,
- be outright rejected,
- or not bring about the value that agile promises.
(See Larman’s Laws)
It is therefore vital that people are coached to find the solutions for themselves. So that they can solve complex adaptive problems.
3. All coaches know how to do everything related to agile transformation
There are so many different types of specialisms needed to achieve organisational agility that no one person could possibly know it all. So different ‘coaches’ specialise in different skills.
At Adventures with Agile (AWA) we identify the skills our clients need and instead of trying to place coaches that know everything, we look to build a coaching competency of the right people with the right balance of skills to achieve the success needed.
This requires a deep knowledge of the whole skills landscape as well as the ability to analyse individual contributions. Competency must cover everything needed for the whole change program.
4. The Scrum Master / Agile Coaching role is a Delivery Manager or Delivery Lead
There is still a lot of confusion around the idea of a servant leader, and as a consequence, Agile Practitioners are often asked to be Delivery Managers, which compromises the effectiveness of the role.
As stated above, Agile Practitioners help others to do stuff. This is not the case of the Delivery Manager. That is a different role.
This has left hiring managers, Agile Coaches, and especially recruiters, baffled as to what the roles do and how to recruit the right person.
Part of the Agile Practitioners role is to remove impediments. This often gets confused with the role of Project or Delivery Manager who looks to find scheduling bottlenecks in the project plan and seek to resolve them.
The difference is that Agile Practitioners make the process transparent and then encourage, coach, and mentor others to find solutions. The Delivery Manager may act like this, but often does not. Often the Delivery Manager will tell the teams the solution and direct the result.
Perhaps most importantly though, the Agile Practitioner is not directly responsible for business results, but jointly responsible with the rest of the wider team. Delivery Managers conversely are responsible directly for driving the results. This has the effect that Agile Practitioners are usually outcome focused and Delivery Managers are output focused.
Of course, this is highly personal, and different people will play both roles very differently.
5. Agile Coaches are better than Scrum Masters
Compounding the problem of role clarity, is the idea that an Agile Coach is somehow higher up the Agile food chain than the Scrum Master. This is reflected in the higher pay and greater responsibility. There even seems to be the idea of the ‘Enterprise Coach’, similar to the once coveted position of ‘Enterprise Architect’, who is the most well paid and experienced coach of them all, residing over the whole enterprise.
What is actually happening here, is that it is not about hierarchy, but about organisational scope. Scrum defined the scope as the single team, and Large Scale Scrum (LeSS), takes this further to include up to 8 teams and beyond. There are different scopes depending on how you want to organise.
As Gerald Weinberg details in his book ‘Secrets of Consulting’, the scope at which one operates at is like spreading jam on toast. If you work with single teams as a Scrum Master, you can provide all your attention on the individuals to make significant long lasting personal changes. However, if you work across many teams, you work on higher level changes that effect many more people, but you won’t have the personal relationships or the deep personal change with each person in every team.
The more toast you cover the thinner the jam spreads.
Each person must choose where they want to operate: more people with less connection, or less people with deeper personal change.
Organisational change is not made simply by optimising teams. Once we get more than just a few teams working together on a product or service, the systems dynamics change, and we need to look at optimising the whole system not just the teams. Likewise, the challenges of managing a large portfolio of work is very different than managing a single backlog for one or two teams.
Being a good Scrum Master is hard and requires deep skills, but these are different skills than someone operating across multiple teams or with leadership teams. Neither role is better or worse.
The idea of hierarchy only comes because of the reflection in the hierarchical organisations that most people coach within, and the reflection of pay grades with those being coached.
At all levels of scope, the same set of core skills (coaching, mentoring, facilitating, and training) still stand. The difference between mentoring and coaching is fundamental because there are two distinct parts to adopting agile. These are process and people. This is independent of scope.
6. Once you are a coach you don’t need to learn any more
Many organisations and some coaches have the belief that once you are a coach you have mastered the profession and that is the end of it. For example, if you complete the 2 days training for a Scrum Master, you can now do the whole role. Or if you employ a coach, that coach just goes about their day-to-day without having coaching themselves or continuing their learning and training.
Instead, Agile Practitioners need coaching too. Coaches often have a lot of their own issues to resolve to better serve those around them. Most professional coaches have coaches of their own. Agile coaches are no different. When working to deeply help others we need to first work on ourselves, and this is a continuous learning journey, that most likely never ends. It is important that this is understood when becoming a coach and when hiring coaches, as this requires an ongoing budget, time, and discipline.
Destroying the misconceptions
At AWA, we have designed a program of change that combines the practices (mentoring) with behavioural change goals (coaching) and covers the different organisational scopes required.
I strongly urge Scrum Masters and Agile Coaches to investigate the world of Professional Coaching as well as the core Agile processes.
We run a 3-day training ICAgile Certified course on Agile Team Coaching that covers operating at different scopes using both mentoring and coaching. You can see the 3-day agenda and secure your seat here.
Thank you to the AWA Support Network for all their feedback and contributions to this article.
Simon Powers is the founder of Adventures with Agile, the global community of practice for agile and organizational change. Over the last decade Simon has worked in organizations moving towards agile ways of working, his approach has led him to create a series of ICAgile Certified Enterprise Agile Coaching training courses, which have received high praise from both the communities in London and worldwide.