I think I have the perfect group of people in this forum to find a brilliant answer to these questions
a) when does it make sense to have a Scrum Master, a Team Lead/Coach, and an Agile Coach (and when can I leave them aside!)?
b) does it make sense to have all of them in parallel and how would they interact?
c) are there arguments in favor/against combining them in one person?
Scrum Masters, Team Leads/Coaches, and/or Agile Coaches
Wow… this should be fun…
I (probably) understand what you mean by:
- A Scrum Master
- An Agile Coach
But I’m not clear or
- Team Lead/Coach
The part the I’m fuzzy on is the “/Coach”
“Team Lead” I get… but unpack what you mean by “/Coach”
And then strap in
Let’s drop titles then and look at roles and systems.
Some stuff from Lyssa’s Adkin’s play book:
What are you trying to influence?
- Individuals? Teams? Programs? Organizations?
- Mindsets, practices, relationships, environments?
Don’t know? Try a few retros to expose the system to itself:
I was hoping for a nice interpretation of Team Coach
Trying not to put too much background to this question - as it might get misleading - it seems like I need to add a little context:
- Imagine, there is an agile transformation going on. People and teams shall be empowered. So we form teams.
- As we start from a hierarchy, there are people in place, who have been responsible for groups of people. We could call them team leads. But as we are looking for an agile organization, where teams are empowered by end-to-end responsibility, we tend to call them team coaches and make them responsible for the organization of teams.
- As teams are empowered, they choose to have Scrum Masters, who help them with facilitation of their procedures and keeps hold of principles in the team.
- Finally an agile organization still needs to have some guiding principles, so we add agile coaches, who keep control over practices.
And here we go: we have Scrum Masters, Team Coaches, and Agile Coaches.
Hurray! Looking at the four quadrants it feels like this could be mapped on the definitions:
IT: Scrum Master - makes sure practices are followed by individuals in a team
ITS: Agile Coach - ensures an appropriate environment for implementing the agile philopsophy
WE: Team Coach - works with teams in how to take ownership as a group, working with the existing relationships
and there would be
I: Personal Coach/Mentor - works with individuals on their personal acting and objectives towards an agile mindset
I have never seen it like this, but it makes perfectly sense to me. Thanks so much @andycleff!
Hello! My take on it is this …
I - the team is responsible for this but the SM is responsible for coaching the team in this area as well.
WE, this is also the team and SM.
IT, this is the team, SM, and technical leads and or managers that can help coach.
ITS, this is the SM AND most importantly management,
An Agile coach fits in with all four quadrants as someone who can coach across evreything. I don’t see it as a permanent thing though for a team at some point the SM should mature enough to become the teams Agile coach but it could take a good coach to help get them there. (And may take a while)
Guess what is the answer from a Scrum Master and a Team Lead (who is supposed to coach rather than tell)?
Yes, they also will claim that they will fit all four quadrants.
It is exactly my dilemma. When I ask them what they could do, they will tell they can a do lot. But this ends in overlapping responsibilities and a clash on accountability.
So how do these roles differentiate, so I have clear principles to follow? Or is one or even two of the roles obsolete?
Going back to the original question format:
A) I find I need a scrum master to facilitate daily team process and guardrails, they may (based on their experience) also be a local agile guide/coach. But they might be green, and need to be coached by someone elsewhere. A team lead could fill the role of senior technical… the person who clarifies direction when the team can’t self-manage, or a senior voice that guides technical skills based on experience (which could include pair programming and TDD, so I see how someone could split this from the other two roles). The Agile Coach is a person who “cross-pollinates” across teams. In environments of 3 or less teams, the Scrum Master and Agile Coach are likely one in the same (my last 3 jobs), but if the company scales, it makes sense to consider an agile coach when either the SM’s are green and need support, or when there are 3 or more SM’s.
B) Yes, if there is scale. I currently behave as a “practice lead” (Agile Coach) that provides training, guidance, and direction for the company’s agile community at large. I work with SM’s, Dev Managers, and PO’s directly. I sit in all retro’s, and I put time into strategic projects to mature the process and tools that support it while the others stay tactical.
C) for me, all arguments are based on scale and experience. Bigger means splitting, smaller means combining. Sometimes you bring in “an experienced expert” to boost your situation.
The “Scope of Agile Coaching” visual is very helpful for me. I’ve been making an incorrect distinction between a teams coach and an agile coach.
Take a look at this. This is the model for Agile Coaching. The bottom three are not expected to be an expert at each area. A Coach should have breadth in all three and develop depth in one (and develop breadth in areas that they currently lack.). It’s impossible to have depth in all of them. Everything else though, a coach is expected to become competent at. It’s a journey and everyone is at a different levels and has different competencies.
yes, and I think the idea of “Coach” applies to both role-cases originally mentioned:
- The Team Lead / Coach
- The Agile Coach
I’d love to get your advice and feedback on something my team and I have been working on for almost two years. We’ve just rolled out our AI-powered agile maturity assessment module, built to help speed up agile transformation.
We’re eager to hear your thoughts, whether it’s positive feedback, suggestions, or even constructive criticism. Your insights will be key to helping us fine-tune the tool and make sure it truly supports agile teams.
We’ve put a ton of work into this, and now we’d really appreciate your input to make it even better. This is Effilix, and we can’t wait to hear what you think!