Coaching is the new black

Every other week I have a geek and gossip breakfast with fellow Agile coach Nathan from Boost New Media. Last time he told me that at Boost they had replaced the word “Scrum Master” with “Agile coach”.

It makes complete sense: The most important part of the Scrum Master role is coaching. Also, many of us have added techniques and principles from Lean, Kanban, Systems Thinking and XP to Scrum which now makes the term “Scrum Master” way too limited to describe the role.

Still, I couldn’t help feeling that someone was stepping on my toes. My knee-jerk reaction was “Well, fine if they’re Agile coaches, then what am I?”
I knew Nathan was right, still something was bugging me.

I realised that what I was missing was a structure that would allow me to categorise and label different type of coaches to better articulate the differences and commonalities between them.

The first distinction I’d like to make is between temporary and permanent coaches. The next is by specialisation.


Permanent and temporary coaches

Temporary coaches

Temporary coaches are transformative: They are change agents who get an organisation or team started and guide them through the learning process of understanding and correctly applying Agile values, principles, concepts, and techniques.

After their work is done temporary coaches hand over to internal, permanent coaches and move on. Temporary coaches are often consultants, and one of their most important tasks is to build-up permanent coaches who can continue their work once they have left.

Success for a temporary coach means that the team keeps improving after the coach has left. Ultimately the temporary coach’s goal is to put themselves out of a job.

The most important skill for a temporary coach is the ability to introduce, manage and communicate new ideas, behaviours and attitudes and to do this together with people rather than “to” them.

Permanent coaches

Permanent coaches stay with a team and/or organisation long after the temporary coach has left. They are often part of a team and their main objective is to make sure that the team keeps improving over time.

Permanent coaches often continue a temporary coach’s work. They focus on continuous improvement and make sure to remind the organisation and team of their agreement to honour Agile values, concepts and principles.

They resemble sports coaches in their nature – much like professional athletes and sports teams Agile teams perform a lot better with a coach.

An important skill for a permanent coach is the ability to maintain enthusiasm about Agile and to keep things fresh and interesting.




Specialty coaches

Apart from length of involvement there’s another dimension that categorises Agile coaches: Specialities. Like medical doctors specialising in different fields of medicine Agile coaches specialise in different areas, too.

Here’s my take on the main types of specialisation within Agile coaching:


Technical coaches

Technical coaches focus on practices such as TDD, refactoring, Behaviour Driven Development, shared code ownership or continuous integration. They work closely with programmers and coaching is often done through pair programming.

Team coaches

Team coaches focus on collaboration, process, leadership and requirements/ideas. They work mostly with team members and are often part of a team as e.g. the Scrum Master. Their main objective is to turn collections of people into collaborative teams and to instill lasting change in behaviours, attitudes and habits to support Agile values within and around the team.

They also interact closely with product managers, business analysts and line managers. Coaching is often done through facilitating events and creating learning opportunities.

Organisational coaches

Organisational coaches mostly work with managers and focus on portfolio management, capacity management, scaling and co-ordination of development efforts, and how the different parts of the organisation work with Agile teams. They mainly help organisations make the necessary adaptations to benefit from Agile. Coaching is mostly done in one-on-one sessions and workshops.


Business coaches

Business coaches work with the product management aspect of the business. They focus on introducing principles and techniques for providing value to end users, stakeholders and organisations and draw from ideas from design thinking, user experience and Lean UX and the lean startup. They mainly help businesses “build the right thing”. Coaching is mostly done in one-on-one sessions and workshops.


Personal coaches 

Personal coaches help individuals define, plan and achieve their professional (and sometimes personal) goals. They take a strictly non-directive approach and guide people towards finding their own solutions. They use techniques and frameworks from personal coaching such as co-active coaching and coaching usually takes place in one-on-one sessions.



Coaches for each specialty can be permanent or temporary.

There is often an overlap of skills and tasks between specialties and most Agile coaches have some knowledge in each area. However, in general Agile coaches specialise in one primary area and have one or two secondary areas that support their primary one.


I’d love to know from Agile coaches what they think about my attempt to categorise coaches. Do you find this useful? And are there specialties I haven’t thought of and that you think are missing?

If you aren’t an Agile coach is this a useful way to shed some light onto the field of Agile coaching?

Also, I’m a temporary coach working with transformations and specialise in organisational coaching with team coaching as a close second. What’s your focus?

Post Tags:
Sandy Mamoli
  • It is interesting as we have had a lot of these conversations about Scrum Masters really being coaches and the various types of coaching.

    January 24, 2013 at 2:30 am
    • What did you come up with? I’d love to know … :-)

      January 24, 2013 at 9:40 am
  • Guest

    Personally I have focused 100% on computer coaching lately. I use various programming languages to make computers perform tasks, correctly, sometimes efficiently and not that seldom even make them stop doing things the should not be doing.
    Coaching computers is quite hard though because they do exactly what you say (every coach’s nightmare) without questioning authority. That is why we computer coaches generally work in teams.

    I guess /everyone/ is a coach these days :) These titles do have a tendency to become pointless after a while. Even if you start out doing a good thing under a title, if you are successful people will adopt the title for something else and all of a sudden you are seen as one of those X that X has become.

    As a rule of thumb I try to communicate what I do rather than what I am. If I just use a title then I may find it does not mean what I thought it meant once.

    January 24, 2013 at 8:05 pm
  • I’d also call our a Business specialty. It seems to me that a weak spot is often in the Product Management part of the business. Does the enterprise really know the “right thing.” Being sure that the “what” is highly valuable to the customers and takes into account their user experience criteria is more in the Lean wheelhouse, and should not be ignored by Scrum and XP shops.

    January 27, 2013 at 4:27 am
    • Hi Karen, I had the business aspects lumped in with the organisational coaches but you’re right they are a specialty on their own. I have updated the blog post to reflect your input. Thank you :-)

      January 28, 2013 at 1:08 pm
      • Jim Rice

        Perfect compliment to your insightful post Sandy. :) Thanks for incorporating!

        January 29, 2013 at 4:21 am
    • Jim Rice

      Karen, I agree. Product Management seems to be a little understood concept for the avg SW dev shop. Lean SW development principles are an underlayment to Agile principles and practices, and generally need to be more fully understood and applied to the concept and discipline of “product” management, IMHO.

      January 29, 2013 at 4:20 am
  • Good post/discussion. I agree with your distinction of “permanent” vs. “temporary” coaching. I typically characterize this in terms of “external” vs. “internal” Coach. Beyond the duration distinction, I also highlight the “commitment” aspect. An internal coach will have more skin in the game, since they’re an employee ostensibly there for the long haul. Plus, an external coach can often provide additional perspective and examples than an internal coach.

    As for your other coaching distinctions, I generally see these as roles, styles and/or levels of coaching. Some, or all, of which may be employed by an Agile Coach.
    Plus, I love the way you’ve illustrated/visualized theses.

    Finally, I think the key distinction that separates an Agile Coach from a ScrumMaster is experience. Experience with multiple teams, in multiple environments, with multiple methods/frameworks and multiple levels within an organization.

    As for me – I’m a temporary/external Coach. I have multiple client organizations, where I coach at the team level, program level and enterprise level. I combine group/team coaching with one-on-one coaching, depending on the needs and situations. I consider myself a “change agent” and focus (as you indicated) on getting things rolling and setting the tone and environment for transformation. Although I am committed to my client’s/teams’ success, I ultimately don’t have a stake in they’re success after I leave.

    January 31, 2013 at 10:06 am
    • I like that you added “commitment” as an important distinction between a temporary/external and permanent/internal coach. As a temporary coach I find that it is often an advantage that I don’t have to play internal politics. On the other hand people sometimes hope they can “wait it out” until the consultant has disappeared and things can go back to normal.

      Interesting what you say about experience being a distinctive factor between an Agile coach and a Scrum Master. I know some very experienced Scrum Masters who have worked in many contexts but I also think that mostly an Agile coach’s journey starts as a Scrum Master. So I’m not entirely sure about that one.

      Thank you for your nice words about my drawings :-)

      January 31, 2013 at 8:44 pm
  • Very interesting post. I do indeed find this sort of dissection of the role very useful. Are you familiar with the Agile Coaching Competency Framework developed by Lyssa Adkins and Michael K. Spayd of the Agile Coaching Institute? I just took their Coaching Agile Teams class, in which they used their framework to very clearly delineate the various constituent skills of coaching. Keeping this framework in mind has already greatly improved my ability to apply the appropriate skill in a given situation, crisply change from skill to skill as needed, and focus my development on the skills where I feel weak. I cannot recommend their training strongly enough. Anyway, I bring it up because your breakdown is very similar to theirs, and it might interest you. Regardless, both breakdowns are indeed useful in that they help coaches navigate what can often seem a nebulous role.

    Along the lines of the eternal question of what Agile coaching is, I’m also reminded of a quote that recently caught my eye:

    “You want a high-performing team. Any action you take towards this is coaching.”
    — Anders Ivarsson, Spotify

    Thanks for the insightful post!

    October 11, 2014 at 1:39 am

Post a Comment