Warum Scrum Master und Agile Coaches von Tech Know-how profitieren

Immer wieder entzündet sich in Gesprächen die Frage: Sollten Scrum Master und Agile Coaches Ahnung von Technologie / „Coding“ haben? Braucht es mehr Tech-Know-how? Oder reicht es aus, wenn sie sich auf den Faktor Mensch konzentrieren?

Zugegeben, als (nicht mehr so aktiver) Software-Entwickler habe ich da eine ganz persönliche Meinung. Doch ich wollte wissen, ob da auch außerhalb meines Gehirns etwas dran ist, und machte mich auf die Suche nach Eindrücken und Perspektiven. Die stelle ich dir hier vor.

Stein des Anstoßes

In einem früheren Blogbeitrag habe ich analysiert, welche Auswirkungen das Streben nach Cloud-native auf Prozesse, Team-Strukturen und Kultur hat. Kurz zusammengefasst: Es verändert sich ganz schön viel.

Das brachte mich zur Erkenntnis, dass sich die typisch gelebte Rolle des Product Owners und Scrum Masters in einem agilen Kontext auch verändern muss. Eben stärker in Richtung Tech Know-how, ohne dass Programmierarbeit verlangt wird.

Meine Leitfragen hierzu sind:

• Wie sonst können denn innovative, werthaltige Produkte gebaut werden, wenn ich (als Product Owner / Scrum Master / Agile Coach) nicht weiß, was technologisch aktuell möglich ist und welche Tech-Trends uns zukünftig erwarten?
• Wie soll ich sonst ein Höchstleistungs-Team formen, wenn ich nicht so gut nachvollziehen kann, wie Entwickler „ticken“, welche Entwicklungs-Techniken wichtig und entscheidend sind?

Schauen wir uns also an, was andere dazu sagen.

Die Sicht von scrum.org

Scrum.org als „Body of knowledge“ und Hersteller der offiziellen PSPO- und PSM-Zertifizierungen spricht von den „The Professional Scrum™ Competencies“.

In der Einleitung zu den Kompetenzen heisst es:

The competencies and their Focus Areas apply to the Scrum Team (Product Owner, Scrum Master, and Developers) and other organizational roles, such as Agile Leaders. Organizations can benefit from using a common understanding of the competencies and focus areas …

Dies ist also der erste Anhaltspunkt dafür, dass die Kompetenzen und Focus Areas auf alle Rollen im Scrum-Team verteilt sind.

Schauen wir uns also an, welche Kompetenzen denn nun damit gemeint sind. Dazu dient die weiterführende Seite  Professional Scrum Competency: Developing and Delivering Products Professionally.

Auf dieser Seite geht es um

1. Das Verständnis emergenter Software-Architekturen
2. Das Verständnis von technische Risiken und wie sie iterativ zu managen sind
3. Die Bedeutung kontinuierlicher Software-Qualität
4. Das Verständnis von CI/CD und deren Umsetzung in der iterativen Software-Entwicklung

… um nur einige Punkte zu nennen.

Dieses Verständnis einerseits und die Fähigkeit, dies dem Team und der Organisation zu vermitteln, sind wichtige Bausteine für das gesamte Scrum-Team.

👉 Zusammengefasst: scrum.org definiert eine Reihe technischer Kern-Kompetenzen, die für alle Rollen im Scrum-Team, also inklusive Product Owner und Scrum Master, wichtig sind.

Agile Coaching Growth Wheel (unterstützt von der Scrum Alliance)

Im Umfeld des Begriffs „Agile Coach“, nirgendwo so richtig eindeutig durch ein Body of Knowledge definiert, findet man nach etwas Suchen das sogenannte Agile Coaching Growth Wheel.

Das Agile Coaching Growth Wheel wurde von Joel Bancroft-Connors, John Barratt, Shannon Carter, Rickard Jones, Martin Lambert, Stacey Louie, Helen Meek, Tom Reynolds, Rohlt Ratan, Andre Rubin, Kubair Shirazee, Mark Spitzer, Mark Summers, Josh Tasker und Maria Thompson entwickelt und unter Creative-Commons-Lizenz gestellt.

Zur Historie äußert sich dieser Konferenzvortrag (Seite 8) von Rob Galen wie folgt: Auf einem Coaching Retreat der Scrum Alliance 2016 haben 10-12 praktizierende Coaches die Profession des Agile Coachings diskutiert und eine erste Version des Agile Coaching Growth Wheels entwickelt.

2021 formierte die Scrum Alliance eine Arbeitsgruppe, um das Wheel weiterzuentwickeln.

Dieses Growth Wheel definiert acht Kernkompetenzen, die von Domänen Know-how unterstützt werden. Wortwörtlich heisst es dort:

The tread around the outside of the wheel represents your domain knowledge. These are knowledge areas that in turn, support the skills of the main competency areas.

Die Kernkompetenzen werden also Domänen Know-how vom unterstützt.

Für das Agile Coaching Domänen Know-how gibt es ebenfalls eine eigene Unterseite, die hierzu etwas mehr ins Detail geht.

The domain knowledge areas around the outside of the Wheel represent supporting expertise that may better help you serve the client and build trust with the team or organization.

Es ist also wichtig, Domänen-Expertise (!) zu haben, damit der Agile Coach besser dem Team und der Organisation dienen kann. Ein ebenfalls wichtiger Punkt ist, dass dadurch auch leichter Vertrauen zu den Personen im Team aufgebaut wird. 

Selbstverständlich erwähnt der Artikel auch ein paar Risiken bei diesem Vorgehen: Habe ich als Agile Coach zu viel Domänen-Know-how (lies: z. B. Tech-Know-how), desto schwieriger soll es fallen, „objektiv“ zu sein. Dies mag ein streitbarer Satz sein. Sollte es doch zur Kernkompetenz eines Agile Coaches gehören, dissoziiert in der Arbeit mit den Menschen zu arbeiten.

Ich verstehe die Vorsicht in dem genannten Artikel, nicht viel über technische Themen wie Engineering-Praktiken zu schreiben. Gleichwohl weist der Artikel darauf hin, dass ein technisches Verständnis für das Produkt und die Engineering-Praktiken wichtig sei, um überhaupt das Team entwickeln zu können, auf Verbesserungs-Reise gehen zu können.

👉 Zusammengefasst: Auch das Agile Coaching Growth Wheel empfiehlt das Vorhandensein von Domänen-Know-how. Es setzt es sogar voraus, um in den Kernkompetenzen des Agile Coaches einen noch besseren Job für das Team machen zu können.

Walk in the shoes of „Technical Management“

Besagter Rob Galen diskutierte in einem seiner Blogbeiträge die Frage, ob es für Agile Coaches denn wichtig sei, in den Schuhen eines Tech-Managers gelaufen zu sein. Er bezieht sich hier auf Kunden-Dienstleister-Beziehungen.

Aus seiner Sicht haben die besten Agile & Scrum Coaches umfangreiche Erfahrungen in mehreren Pfaden. So zum Beispiel in technischen Führungsrollen, Projektverantwortlichkeiten in verschiedenen Unternehmen und Business-Domänen. Sie haben aber auch in technischen Domänen, zum Beispiel im Umfeld der Business Analyse und des Software Testings gearbeitet.

Zugegeben: Liest man sich die fünf anspruchsvollen Pfade durch, so kann man leicht in ein überforderndes Gefühl kommen. Es hilft, sich auf einen der Kernsätze zu Beginn des Artikels zu fokussieren:

„I think one of the problems here is that the coaches and trainers in these situations don’t have the skills, experience, and courage to truly connect with their client leadership teams. My emphasis here is the experience.“

In einem anderen Artikel, der als Vorüberlegung diente, fasst Rob die Anforderungen an einen Agile Coach wie folgt zusammen:

„In general, knowledge of software development, testing, project management, and team leadership is incredibly helpful for coaches. So look for the breadth, but also the depth.“

Wer hier weiter eintauchen möchte, dem sei auch noch Teil 2 des Artikels empfohlen.

👉 Zusammengefasst: „Did I walk in their shoes?“ ist eine wichtige Fragestellung zur Selbstreflektion eines Scrum Masters & Agile Coaches. Mag der Anspruch von Rob Galen sehr hoch sein, geht es hier viel mehr um die Fähigkeit des Verständnisses für ein technisches Management, für Technologie (Test-Pyramide? Was war dieses Microservices-Ding nochmal?) und Erfahrung im Umfeld dieser Pfade, um gut wirken zu können.

---

Wie können wir Dir helfen?

Grande Dame des Agile Coachings

Man kann zurecht behaupten, dass Lyssa Adkins die Grande Dame des Agile Coachings ist. 2010 hat sie als eine der Ersten dazu beigetragen, die Rolle „Agile Coach“ entstehen zu lassen. Zahlreiche Bücher hat sie seitdem geschrieben und ihre Expertise zusammen mit anderen in die Welt getragen. 2010 hat sie das Agile Coaching Institute gegründet.

Dort ist im Jahr 2011 eine Publikation entstanden, Developing Great Agile Coaches (PDF-Download).

Schon sehr früh hat sie erkannt:

How do we create good (even great) Agile Coaches? We maintain that, as an industry we do not know how.

Im Artikel beschreibt sie das Agile Coach Competency Framework, das aus acht Kern-Kompetenzen besteht.

Eines dieser Kern-Kompetenzen ist Domain Mastery. Dieses wiederum ist aufgeteilt in die drei Teilbereiche

1. Technical Mastery: „get your hands dirty“, z. B. in Bezug auf Architektur, das Vermitteln von Software Craftership durch Mentoring & Teaching
2. Business Mastery: Kenntnis von Business-Strategien und Modellen, Produkt-Innovations-Techniken und weiteren Techniken, die Innovationskraft in Bezug auf Produkt, Prozesse oder Operations haben
3. Transformational Mastery: Fähigkeit, Organisations-Veränderung zu katalysieren

Sie beschreibt, dass es schiwerig ist, dass Agile Coaches alle drei Facetten dieser Domain Mastery beherrschen. Dies sei abhängig vom jeweiligen (Unternehmens-)Kontext. Dennoch legt sie Wert darauf, dass ein gewisses Grundverständnis aus allen drei Facetten beim Agile Coach vorhanden ist.

👉 Zusammengefasst: Schon sehr früh beim Entstehen der Rolle des Agile Coach wurde klar, wie wichtig das Verständnis der Domäne als Agile Coach ist. Domäne bedeutet nicht nur das Verständnis für das Business, sondern eben auch ein (hier als sehr tief dargestelltes) Verständnis für Technologie, Technologie-Arbeit und Engineering-Praktiken.

Value-Maximierung ohne Domänen-Know-how?

Gemäß dem Scrum Guide ist der Scrum Master ein wichtiger Verbündeter des Product Owners und des gesamten Scrum-Teams. Schließlich soll das gesamte Scrum-Team darauf fokussiert werden, „high value increments“ zu erzeugen. In vielen Fällen also high-value-Inkremente eines Software-Produkts.

Martin Hinshelwood, ein bekannter Professional Scrum Trainer, geht in diesem Blogbeitrag der Frage nach, ob technische Skills als Voraussetzung für den Scrum Master gesehen werden sollten.

Das Entscheidende an diesem Blogbeitrag sind folgende Abschnitte:

That is only part of the Scrum Master role, I also need to teach & mentor the Product Owner to become better at realising value; for that, I need to have an understanding of the context within which they operate.

und

While I would not expect a Scrum Master to have to be able to do everything that the Engineering team members can, they need to understand what the mastery of that profession looks like as well as the context within which the engineering team are practising. For example, they should be able to tell if TDD is appropriate for this team, what does it look like, and if so, are they doing it well.

Was ist also Mastery in der Profession des Software Engineers in der jeweiligen Business-Domäne (z. B. Entwicklung einer Banking-Software)?

Wie kann das Team gut gecoached werden, sich weiterzuentwickeln – nicht nur persönlich, sondern auch technisch? Wie kann ich als Scrum Master den Product Owner dabei unterstützen, das Maximum an Value aus dem Produkt herauszuholen?

👉 Zusammengefasst: Der Scrum Guide selbst gibt, obwohl er in den letzten Jahren immer weiter abgespeckt und vereinfacht wurde, die Leitlinie vor, dass der Scrum Master als Teil des Teams dazu dient, high-value-Inkremente liefern zu können. Martin Hinshelwood gliedert dies in seinem Artikel in die Teilbereiche Technical Mastery, Business Mastery und Organisational Transformational Mastery auf; analog zum Agile Coach Competency Framework. Schlüsselfragen hierbei sind die Betrachtung der Unterstützungsleistung für den Product Owner sowie dem Rest des Teams. Ohne grundlegendes (technisches) Domänen-Verständnis verpufft das Potenzial, das ein Scrum Master leisten könnte.

Quo vadis, Scrum Master & Agile Coach?

Alle Quellen, die ich so betrachte, sprechen also von Domänen-Know-how, das beim Scrum Master und Agile Coach gefestigt sein muss.

Digitalisierung und Technologien schreiten immer schneller und weiter voran. Scrum Master und Agile Coaches sind eine wichtige Unterstützungs-Rolle in einem und für ein Team.

Ein gutes, robustes Verständnis von Entwicklungs-Techniken und -Praktiken sorgt dafür, dass Scrum Master und Agile Coaches dem Team auf Augenhöhe helfen können, sich gut weiterzuentwickeln. Um „high value“-Inkremente des Produkts zu liefern.

Und das eben mithilfe einer von vielen weiteren Kern-Kompetenzen.