Triadic Contracting

Why explicit coaching is impossible in Scrum!

A bold statement, admittedly. Let’s see whether you share it after reading this article.

Let’s start at the very beginning. Scrum Masters are responsible for the effectiveness of the Scrum Team. According to the Scrum Guide, they are supposed to coach team members in “self-management and cross-functionality”1. Coaching is a central component2 in achieving the target states described in the Scrum Guide. How exactly Scrum Masters implement this is up to them, as is much else.

If you take a closer look at explicit coaching (explicit = with clarification of the mandate; implicit = without clarification of the mandate) and systemic consulting, one essential – if not the most essential – component is the clarification of the mandate3 4 5 6. It clarifies which goal the coach works toward together with the coachee. The goal is usually defined at the beginning and can be adjusted at any time during the coaching. This makes sense, because early insights may reveal that the initial target states would not deliver the desired results.

An example from classic (explicit) coaching: the original goal was professional development of leadership skills. In working on this, it may turn out that the leadership role itself, contrary to the initial assumption, does not fit the person’s personality. A new professional orientation emerges during the coaching as a new goal.

Let’s look at how the situation appears in the Scrum framework. Which mandate is documented, when, and with whom? In the framework, each person brings their own understanding and interpretation of Scrum based on their experience and prior knowledge. These rarely match completely. The real question is how large the deviations between the involved parties are, not whether they exist. Conflicting goals, expectations, and approaches are therefore more the rule than the exception. Entirely normal.

How can that be? In most cases, there is no clarification of the mandate between the organization, the team member, and the Scrum Master. That is our triad. There is an agreement (contract including mandates) between the organization and the team member (“You develop software using Scrum.”) and an agreement (contract including mandates) between the organization and the Scrum Master (“You support the team and the organization in becoming more agile.”). If we ignore for a moment the differing quality of these agreements, we can see the essential point.

And this is my fundamental criticism of Scrum: there is no intended agreement including clarification of the mandate between team member and Scrum Master and – even more serious – hardly any effective ways to compensate for this.

Figure 1: Clarifying the mandate in our triad

You may be asking yourself why the Scrum Master does not simply obtain a mandate from the team member on the important topics.

That would be as if your mother-in-law (who also lives in the house) suggested that you go on vacation to Sicily and rent a boat there because she is convinced it would do you good.

However, you would much rather go hiking in Iceland and would probably not be willing to invest much energy in your mother-in-law’s suggestion, because you do not share this goal. It is a different matter if you yourself arrive at the idea of Sicily in conversation with your mother-in-law, isn’t it?

What can the consequences be?

Numerous scenarios are conceivable: If, for example, the underlying assumptions, target states, methods, the team member’s self-image, and the Scrum Master’s external view are similar, there is a promising overlap (e.g., how open and respectful the team which process changes, tools, and configurations help achieve the goals). This leads to continuous improvements. Team members themselves have good ideas, like to try them out, and increasingly organize themselves. A Scrum Master can certainly accelerate this in many ways, but fundamentally the team is on the right path even without the Scrum Master.

But what if the assumptions, target states, methods, and especially the self-image of the team members and the external image held by the Scrum Master diverge strongly (team members: “We are very agile!”; Scrum Master: “We have lots of potential!”)? The Scrum Master sees many opportunities for optimization, while the majority of team members do not, because from their perspective and experience everything is going very well.

“Inspect and Adapt” hardly works, if at all, because problems are not perceived or not accepted. Consequently, there is only limited willingness to try out new ideas from the Scrum Master. Understandably so. This effect can intensify in project situations the more demanding the situation becomes.

Imagine your mother-in-law wants to redesign the garden two weeks before your big birthday party. How open are you to that? It could get better, but it doesn’t have to. So, it is understandable that resistance in the team grows in proportion to how much the Scrum Master wants to implement change.

In such a situation, coaching without a mandate (implicit) is also unlikely to be successful, because many team members have no motivation to change anything (“We are already working in a very agile and successful way.”), and the goals of the team members (“Keep going as we are!”) and the Scrum Master (“Let’s tap into our potential!”) differ too greatly. Without a common goal, it is difficult to find a good path toward it.

That is like your mother-in-law telling you where to buy your pork chops because they are good and cheap there, while you want to eat salad.

How can such a vicious circle be prevented or broken?

One possibility is to focus on clarification of the mandate. I see two options here.

On the one hand, the mandate can be worked out in a 1:1 conversation between each team member and Scrum Master at the start of the project. Individually clarifying development goals gives the Scrum Master greater room for manoeuvre, increases the team member’s commitment, and legitimizes later follow-ups on this agreement.

However, this approach requires many preconditions on the part of the team member such as motivation, openness, and above all the ability to reflect. The fewer these and other qualities are present, the greater the need for development and the less likely it is to occur. Even if these qualities are sufficiently present, there will inevitably remain a gap between the optimizations aimed for by the team member and those aimed for by the Scrum Master. There remains the risk that a large deviation will have a lasting negative effect on project success. Since the initiative in the case of deviations does not come from the team member, explicit coaching cannot take place here either.

On the other hand, the Scrum Master can define shared goals with the entire team (e.g., based on a well-visualized questionnaire evaluation). “We want to become so bold that we regularly try out new things and redirect individual requests to the PO or SM.” or “We want to increase customer satisfaction by 25%.” are goals that can be used to sharpen sensitivity and focus within the team.

But here too, the Scrum Master depends on the team’s commitment. Defining a suitable team goal can also be very demanding. The softer the topic, the more difficult it becomes. When you think of motivation, self-commitment, and openness, measurability appears to be more difficult. A detailed definition of criteria can quickly be perceived as controlling and have negative effects.

So even here, there remain large gaps in which the Scrum Master may have no impact. Again, the initiative does not come from the team, and topics may even be imposed by the Scrum Master, with the corresponding effect.

How can these open “impact gaps” be positively influenced?

By using a technique that implicitly generates insights even without a mandate, motivation, or a shared goal: systemic questioning techniques. If you want to become the kind of mother-in-law in our analogy with whom conversation partners develop good ideas, then this article is of interest to you.

Conclusion

In the Scrum framework, it is normal to allow a lot of freedom. Typically, however, there are many promising approaches for the individual challenges:

  • How do I create the backlog?
  • How do we estimate?
  • Which item-processing workflow fits us?

But the missing clarification of the mandate turns out to be a tough nut to crack – in some cases perhaps impossible to crack – and therefore a structural weakness. Particularly disadvantageous is the complementary relationship between the need for development and the likelihood of impact. The greater the need in individual team members (e.g., due to low motivation, openness, or ability to reflect), the lower the likelihood of effective implicit coaching without a mandate. A dilemma where additional solution approaches (also from you) are generally helpful.

In conclusion, the central question remains: How can explicit coaching be implemented effectively within the Scrum framework?

I wish you much success and thank you for your attention.

Please note that throughout the article, terms such as “Scrum Master” are used in a gender-neutral way and always include all genders equally.

Bibliography

Barthelmess, Manuel: Die systemische Haltung. Was systemisches Arbeiten im Kern ausmacht, Göttingen: Vandenhoeck & Ruprecht GmbH & Co. KG 2016

Fischer-Epe, Maren: COACHING: Miteinander Ziele erreichen, Überarbeitete Neuausgabe, Reinbek bei Hamburg: Rowohlt Taschenbuch Verlag GmbH 2004

McShane, Niall: Responsive Agile Coaching. How to accelerate your coaching outcomes with meaningful conversations, USA: Lifestyle Entrepreneurs Press 2020

Radatz, Sonja: Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen, 10. unveränderte Auflage, Wolkersdorf, Österreich: Literatur-VSM e.U. 2018

Schlippe, Arist von / Schweitzer, Jochen: Lehrbuch der systemischen Therapie und Beratung I. Das Grundlagenwissen, Göttingen: Vandenhoeck & Ruprecht GmbH & Co. KG 2012

Schwaber, Ken / Sutherland, Jeff: Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln, 2020

  1. Schwaber/Sutherland 2020, S. 7 ↩︎
  2. vgl. McShane 2020, S. 11 ↩︎
  3. vgl. Barthelmess 2016, S. 146 ff, S. 165 ff ↩︎
  4. vgl. Fischer-Epe 2002, S. 26 ↩︎
  5. vgl. Radatz 2018, S. 130 ff ↩︎
  6. Schlippe/Schweitzer 2012, S. 235 ff ↩︎

This post was written by: