Agile Coaches: When They Help and When They Create Dependency

Agile coaches help when a company wants to build capabilities it lacks internally, and they create dependency when their engagement has no end date and no handover to internal roles. The decision falls at the design of the engagement: goal, outcome metric, period and handover plan must be in place before the first working day. This article sets out criteria, a stage model for the support and a checklist for executives facing the renewal of a coaching engagement.

In recent years many companies have brought in agile coaches to introduce Scrum or Kanban. After the first year, the same question arises in many cases: do the teams work better, or do they mainly work with the method for as long as somebody stands next to them? This article answers it from a delivery perspective and compares the benefit of a coach with the effects that executives actually see in their figures.

What does an agile coach do in a company?

An agile coach helps teams, managers and the organisation to build and apply agile ways of working. The 2020 Scrum Guide describes the Scrum Master role in similarly broad terms: the Scrum Master serves the team and the organisation, supports self-management and cross-functional collaboration, and helps the organisation plan and adopt Scrum. An external coach takes on these tasks for a period or complements internal roles.

In her 2010 book “Coaching Agile Teams”, Lyssa Adkins describes several stances that a coach takes depending on the situation: teaching methods, mentoring, helping with conflict, facilitating and demanding performance. A useful distinction follows for steering by the executive team. The more a coach teaches and guides, the greater the contribution to capability building, and the more the coach makes decisions or keeps processes running personally, the greater the dependency. In “Helping” (2009) and in his research on process consultation, Edgar Schein describes that the person seeking help remains the owner of the problem and that the relationship with the helper must not push them into an inferior role. For coaching this yields a test for every intervention: does it raise the capability within the team, or does the coach take the decision away from the team?

When does an agile coach help?

An agile coach helps when three conditions coincide: a concrete delivery problem has been named, the capability to solve it is missing internally, and there are people in the company who are to take it over. If one of the three is absent, the contribution stays limited. Without a delivery problem, coaching becomes an end in itself, without an internal capability gap a colleague is enough, and without somebody to take over, every improvement ends when the coach leaves.

Typical occasions in which a coach has an effect are the start of the first teams with a new method, the training of internal Scrum Masters or product owners, the clarification of roles and decision paths between a business unit and development, and the facilitation of a deadlocked collaboration between two departments. In these cases a coach brings experience from other organisations and shortens the learning time that a team would otherwise pay for through its own mistakes. What remains of a method after the first year in the company is described in the article on Scrum in mid-sized companies.

How do you recognise that a coach is creating dependency?

You recognise dependency by patterns in the teams' daily work that do not change over months. The first pattern is the coach as facilitator: rituals take place only when the coach leads them and are dropped in the coach's absence. The second is the coach as decision-maker, to whom teams pass on questions about priority or approach that they could answer themselves. The third is an engagement that is extended from quarter to quarter without a target value being named. The fourth is reporting that counts activities, such as workshops held, but not effects on lead time or quality. The fifth is the absence of internal successors: after a year, no employee has taken over the coach's tasks.

There is also an economic finding. Anyone who names no point at which the support ends pays for a service that the team could by now provide itself.

In which stages should the support run?

Good support runs in four stages in which the coach gradually hands over responsibility. Each stage has a criterion by which the executive team recognises whether the next one can begin.

1. Guide: the coach demonstrates the method, facilitates the first cycles and explains the reasoning behind each rule. Criterion for the end of the stage: the team describes the rules and their purpose in its own words.
2. Accompany: internal facilitators lead the rituals while the coach observes and gives feedback. Criterion: rituals run without the coach and lead to decisions.
3. Advise: the coach is available on call and joins for new questions, for example when a second team starts or dependencies between teams emerge. Criterion: requests become less frequent and more demanding.
4. Hand over: internal roles hold the responsibility and the engagement ends with a documented position. Criterion: the metrics hold for at least one quarter without the coach's involvement.

Each stage is measured against figures the customer sees. These include cycle time and throughput, as described in the article on flow metrics. Attendance at training courses and the number of certificates say little about whether the work runs better.

Which questions should the executive team settle before the engagement?

Before awarding or renewing a coaching engagement, the executive team should answer eight questions. They force the goal to be named and the coach's role to be weighed against internal options.

Two points are often overlooked in practice. The first is the role of managers: teams can apply agile ways of working only if leadership takes decisions promptly and does not change priorities daily. A coach who works with teams without any change in management behaviour achieves local improvements at best. The second is the organisational structure: if teams are cut so that every delivery needs three departments, coaching the rituals does not help. How teams are cut along the flow of work is explained in the article on Team Topologies.

Agile coaches and Niehues Consulting

Niehues Consulting is a Düsseldorf consultancy for AI management and organisation design from the delivery perspective. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. Within delivery management he works as delivery manager, project manager or product owner, and in organisation design he defines roles and decision paths so that teams deliver without permanent support.

The approach follows the Niehues Delivery Model with its three phases. Three of its review questions matter most for the question of a coach: Who decides, who delivers, who uses? Which roles and decision paths does operation need? Are the users enabled and the processes adapted? The Delivery Model requires that every improvement passes into operation and remains there on its own strength. The entry point is a free initial consultation of 30 minutes, which you can arrange via contact.