Single Layer Agile Coaching

From go-ELSE
Revision as of 23:49, 26 January 2024 by Ppugliese (talk | contribs) (Created page with "=Description= Avoid differentiating among different types of "coaching"! There is only one role! It's not essential how the role is called. Some organisations prefer to call it Scrum Master, others Agile Coach. The issue to avoid is to create a multi-stratum coaching organisation, with some people working with Teams and others with Management. =Rationale= In a single Team, the coaching role is in a single person, i.e., no misalignments are possible. At scale, more than...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Description

Avoid differentiating among different types of "coaching"! There is only one role!

It's not essential how the role is called. Some organisations prefer to call it Scrum Master, others Agile Coach. The issue to avoid is to create a multi-stratum coaching organisation, with some people working with Teams and others with Management.

Rationale

In a single Team, the coaching role is in a single person, i.e., no misalignments are possible. At scale, more than one coach will be needed, so the coaches present need to work together, and any role differentiation is problematic in the long term.

Over the last years, there has been a worrying tendency that seems to emerge in the agile coaching community: that there are "enterprise coaches", "agile coaches”, and "scrum masters". And while the former is the cool folk working with the C-levels, the Scrum Masters are those "second class" coaches that deal with teams.

We find this highly damaging for several reasons.

  1. . The reality of many organisations is that there needs to be more communication between the decision-makers and the product developers. This problem is visible through different lenses: from Management organising the teams without understanding them to customer requirements being pushed to developers without any technical reality check. A similar decoupling in the agile coaching practice amplifies these issues instead of solving them.
  2. . It creates a career path in the coaching practice, causing people to try and move to a job "higher in the ladder", thus preventing collaboration among coaches and political games [also] inside the coaching practice.
  3. . It creates a decoupling of information, with different groups of coaching operating without coordination. We've seen this despite all the good intentions and promises of collaborating!
  4. . The differentiation in roles results in a lack of adaptiveness of the coaching practice, i.e. reduced flexibility in accompanying change. The effect is similar to having Component Teams.
  5. . It creates a hierarchy inside the coaching practice, reproducing many common company dysfunctions.

Related Principles

While we hold this principle as valid and important, one notable exception is technical practices. Many great Agile Coaches come from something other than a technical background. Others were great technicians in the past; however, with a combination of not practising enough and the evolutions of the technologies, they are rusty enough not to be able to do mentoring and coaching technical practices anymore. In this case, we expect these Agile Coaches to understand the basics of the technologies used in that product development.