On Lean and Agility

Bild: Pexels / Yan Krukau - Lizenz

Noch einmal zum Thema der neuen Führungsrollen in einem agiler werdenden Umfeld. Dass bei ihrer Ausgestaltung verhindert werden sollte, dass der disziplinarische Vorgesetzte eines Teams auch dessen fachliche oder methodische Leitung innehat, ist eine Einsicht, die sich immer mehr durchsetzt. Alles andere würde zwangsläufig zu einer (Teil-)Entmachtung des Product Owners oder Product Managers führen, da dieser dann nicht mehr der Einzige wäre, der seinem Team Ziele vorgibt.

Die sich zur Zeit etablierende Rolle des People Managers wird dieser Anforderung gerecht, indem sie in den meisten Fällen völlig aus dem operativen Geschäft herausgelöst wird. Das verhindert zwar Zielkonflikte, die Entkoppelung von der täglichen Arbeit macht es aber für viele People Manager sehr schwer zu erkennen, welche Mitarbeiter sich Versetzungen, Beförderungen oder Gehaltserhöhungen verdient haben und welche nicht (mehr dazu hier).

Manche Unternehmen versuchen daher einen dritten Weg zu gehen. In ihm wird die disziplinarische Führung nur in Teilzeit ausgeübt (zumindest auf den unteren Hierarchie-Ebenen), wodurch weiter ein unmittelbarer Bezug zur eigentlichen Arbeit gewahrt wird. Ausserdem bleibt ein Teil der fachlichen Führung erhalten, aber nicht in Bezug darauf was gemacht wird, sondern wie es gemacht wird (eine wichtige Unterscheidung).

In diesem Modell bleibt auf diese Weise die Entscheidung darüber welche Kundenprobleme gelöst werden oder welche Features gebaut werden (→ die Product Ownership) ausschliesslich beim Product Owner oder Product Manager, die Grundlage auf der die die disziplinarische Führungsrolle über Versetzungen, Beförderungen oder Gehaltserhöhungen entscheidet ist dagegen die Qualität der Arbeit - idealerweise anhand transparenter und im voraus feststehender Kriterien.

In diesem Modell gibt es dann nochmal zwei verschiedene Arten der Ausgestaltung. Eine allgemein übliche Bezeichnung hat sich für sie noch nicht durchgesetzt, um sie hier beschreiben zu können möchte ich aber die Titel aus den vermutlich jeweils bekanntesten Anwendungsfällen benutzen: den Chapter Lead aus dem Spotify Model (ja, ich weiss) und den Group Lead (japanisch Hanchô / 班長) aus dem Toyota Production System.

Chapter Lead

Das entscheidende Erkennungsmerkmal des Chapter Leads ist seine Einordnung in eine Matrix-Organisation. Seine Einheit (das Chapter) arbeitet nicht selbst an einem Produkt oder Feature, sondern besteht aus gleichartigen Spezialisten (z.B. UX, QA oder Kundenservice) die über mehrere produktorientierte Teams verteilt sind. Dieser sehr ähnliche Arbeitsgegenstand aller Chapter-Mitglieder ermöglicht es dem Chapter Lead, gemeinsame Qualitätskriterien zu erstellen (auch teamübergreifend).

Group Lead

Im Umfeld der Group Lead-Rolle sind Ablauf- und Aufbauorganisation identisch, es gibt also keine Matrix-Organisation. Eine Gruppe verantwortet in Gänze ein (Teil-)Produkt, ein Feature oder eine Fertigungsstation, und umfasst alle dafür notwendigen beruflichen Spezialisten. Für den Group Lead bedeutet das, dass er einen besseren Einblick in die Zusammenarbeit der Spezialisten hat als der Chapter Lead, dafür aber schlechter die jeweiligen Einzelleistungen beurteilen kann.

Um es vereinfacht zusammenzufassen: sowohl Chapter Leads als auch Group Leads überlassen die Product Ownership dem Product Owner, bzw. Produktmanager und haben stattdessen die Qualität als ihr Führungsgebiet. Während das bei dem stark spezialisierten Chapter Lead vor allem die Qualität der Arbeitsvorgänge ist, ist es bei dem eher generalistischen Group Lead vor allem die Qualität des jeweiligen (Teil-)Produkts. Beide Ausprägungen haben Vor- und Nachteile, keine ist besser als die andere.

Zur Sicherheit noch ein zweites Mal zur Klarstellung: die beiden hier genutzten Begriffe sind nicht offiziell oder allgemein anerkannt, dass ich sie hier benutzt habe, hat nur den Zweck, zwei Rollen, für die es noch keinen feststehenden Namen gibt, beschreiben zu können. Im Einzelfall können die Benennungen ganz anders sein. Das ist auch unproblematisch, wichtiger als die Bezeichnung ist das Verständnis der dahinterstehenden Ausgestaltungen.

Das ist auch der finale Ratschlag, bzw. das Fazit dieses Artikels: wichtiger als die schönen englischen oder japanischen Namen sind die Gestaltungsparameter: wie kann eine disziplinarische Führungsrolle so gestaltet werden, dass sie die Product Ownership des Product Owner/Produktmanager nicht untergräbt, trotzdem in der Lage ist auf sachlicher Ebene über über Versetzungen, Beförderungen oder Gehaltserhöhungen zu entscheiden und einen für alle klar erkennbaren Verantwortungsbereich hat?

Nachdem ich in der Vergangenheits bereits mehrfach Videos von Chad Beier hier eingebunden habe, habe ich seinen Youtube-Kanal irgendwie aus den Augen verloren. Nachdem er mir jetzt wieder in den Sinn gekommen ist, habe ich dort tatsächlich einige neue "agilisierte" Coverversionen bekannter Popsongs gefunden. Wie immer ein großer Spass.

Bild: Pexels / Polina Tankilevitch - Lizenz

Eines der kurioseren soziologischen Phänomene der letzten Jahre ist das so genannte Virtue Signaling. Hinter diesem Begriff verbirgt sich das demonstrative öffentliche Kommunizieren von Standpunkten die als moralisch gut oder sogar überlegen wahrgenommen werden. Zweck dieser Handlung ist neben der Selbstvergewisserung die Symbolisierung einer Gruppenzugehörigkeit, die Abgrenzung zu anderen, als unmoralisch empfundenen Gruppen und die Beanspruchung einer Diskurs-Dominanz.

Virtue Signaling tritt vor allem im politischen Kontext auf, greift aber auch in der agilen Community um sich, etwa auf Meetups und Konferenzen, in Social Media oder Fachpublikationen. Verbunden ist es hier fast immer mit dem Kampf gegen eine (vermeintliche) Verfälschung und übermässige Kommerzialisierung der Idee der agilen Produktentwicklung, bzw. mit der Positionierung als Bewahrer der (idealisierten) ursprünglichen Absichten und Überzeugungen.

Mit der Zeit haben sich in diesem Zusammenhang einige populäre, stetig wiederholte Standard-Botschaften herausgebildet. Sie alle haben einen realen Kern, sprechen also tatsächliche Good Practices und Antipattern an, definieren sich aber sehr stark durch die Ablehnung bestimmter Missstände, wodurch sie oft von einem eher kritischen oder anprangernden Grundton durchzogen werden und in ihrem Dogmatismus mitunter über das Ziel hinausschiessen können.

Mit dieser Vorrede im Hintergrund - hier sind einige der am häufigsten vorgetragenen "agilen Virtue Signals", samt einer kleinen Einordnung:

Wir haben keinen Prozess, wir verhalten uns einfach vernünftig

Was steckt dahinter? Die Ablehnung der sehr stark ausufernden Prozessbeschreibungen, die SAFe, Disciplined Agile, Scrumstudy und weitere kommerzialisierte Anbieter verfasst haben. Diese werden als im Widerspruch stehend zu Selbstorganisation und Inspect & Adapt wahrgenommen.

Was ist davon zu halten? Die Grundidee mag vernünftig sein, in der Umsetzung stösst sie aber schnell an Grenzen. In jeder Situation neu zu erforschen und zu verhandeln was gerade die beste Lösung ist, selbst wenn es bereits passende Lösungen gibt, wäre verlangsamend und unwirtschaftlich.

Agile ist ein Mindset

Was steckt dahinter? Die Ablehnung der Reduktion von agilem Arbeiten auf spezifische Meetings, Rollen und Anforderungsformate, ohne das nötige Hinterfragen klassischer Welt- und Menschenbilder, die ohne Veränderung auch gutgemeinte Prozesse hierarchisch und kontrollierend umformen können.

Was ist davon zu halten? Ein kontroverses Thema. Für viele Agilisten ist dieser Spruch eine unverrückbare Wahrheit, die sie ständig rezitieren, für andere eine nicht zielführende Verlagerung systemischer Probleme auf die persönliche Ebene. Auf jeden Fall gut für lebhafte Diskussionen.

Kanban ist agiler als Scrum

Was steckt dahinter? Schlechte Erfahrungen mit rigide durchgesetztem und dogmatisch befolgtem Scrum, vor allem in Kontexten in denen Sprints und Sprintziele nur schlecht funktionieren können. Umgekehrt kommen gute Erfahrungen mit den schlanken und flexiblen Kanban-Prozessen dazu.

Was ist davon zu halten? In den meisten Fällen dürften derartige Äusserungen darauf beruhen, dass Scrum falsch (oder an einer nicht passenden Stelle) umgesetzt wurde. Grundsätzlich ist Kanban völlig in Ordnung, es ist aber nicht "Scrum ohne komische Vorschriften" (und beide sind ähnlich agil).

Extreme Programming ist das beste agile Framework

Was steckt dahinter? Zum einen Vergangenheitsverklärung - vor der Kommerzialisierungswelle der 2000er Jahre war XP das dominante Framework. Zum anderen der Ursprung vieler technischer agiler Praktiken in XP, ohne die Agilität (in der IT) nicht funktionieren kann.

Was ist davon zu halten? Wenn wirklich die technische Dimension im Vordergrund steht ist XP tatsächlich eines der besten agilen Frameworks (zumindest in der IT). Man muss sich nur bewusst machen, dass es seit ca. 20 Jahren nicht weiterentwickelt wurde und keinen Skalierungsansatz hat.

Story Points und Velocity gehören nicht zur Agilität

Was steckt dahinter? Die Ablehnung von Cargo Cult-Praktiken. Story Points und Velocity können bei falschem Verständnis die Illusion erzeugen, dass auch in volatilen und komplexen Umgebungen klassische Zeit- und Aufwandsplanung möglich ist. Dieses Missbrauchspotential führt zu einer Komplett-Ablehnung.

Was ist davon zu halten? Zum einen ist es richtig, dass Story Points und Velocity in keinem agilen Framework verpflichtend sind, man sollte aber zwischen Symptom und Root Cause differenzieren. Nicht diese Praktiken sind das Problem, sondern eher die Motive für ihren falschen Einsatz.

SAFe ist nicht agil

Was steckt dahinter? Die Ablehnung von zu umfangreichen oder falsch eingesetzten Regelwerken und Praktiken (siehe oben) und die Ablehnung zu starker Kommerzialisierung, für die SAFe mit seinen jährlich zu erneuernden, teuren Zertifizierungen das bekannteste Beispiel ist (siehe unten).

Was ist davon zu halten? Auch hier wieder: Ein kontroverses Thema. Für viele Agilisten ist die vehemente Ablehnung von SAFe Teil ihres Selbstverständnisses, andere bestehen darauf, auch mit SAFe agil arbeiten zu können (was z.T. sogar stimmen kann). Wie so oft - es kommt darauf an.

Wir machen Wir machen #NoBacklogs / #NoEstimates

Was steckt dahinter? Schlechte Erfahrungen mit zu detaillierten Planungen und dem Schätz-Zwang unschätzbarer Tasks. Aus Sorge, dass selbst gutgemeinte Ansätze zu diesem Zweck missbraucht werden können, kommt es auch hier zu kategorischen Ablehnungen von Planung und Aufwandsschätzung.

Was ist davon zu halten? Wenig, hier wird über das Ziel hinausgeschossen. Backlogs entstehen automatisch sobald unerledigte Arbeit da ist und Aufwandsschätzungen sind selbst dann gegeben wenn man sich fragt ob etwas im nächsten Monat machbar ist. Das zu vermeiden ist unmöglich.

Jira und andere Ticket-Tools sind nicht agil

Was steckt dahinter? Zum einen schlechte Benutzungserfahrungen, wie z.B. die, dass manche agilen Praktiken und Workflows in ihnen nicht abbildbar sind, zum Anderen schlechte Erfahrungen mit zu restiktiver Administration und Berechtigungsvergabe.

Was ist davon zu halten? Wie bei Story Points und Velocity sollte man auch hier zwischen Symptom und Root Cause differenzieren. Jira & Co haben ihre Schwächen (welches Tool hat die nicht?), meistens ist aber der nicht zielführende Einsatz das Problem, nicht das Tool selbst.

Selbst Spotify benutzt das Spotify Model nicht

Was steckt dahinter? Die Erzählung, dass das Spotify Model mit seinen Tribes, Squads, Gilden und Chaptern nur eine temporäre Momentaufnahme aus einer längeren Entwicklung war und nie als Blaupause für andere Organisationen gedacht gewesen ist (obwohl genau das passiert ist).

Was ist davon zu halten? Es kommt darauf an. Wenn man unter dem Spotify Model nur die Matrix-Organisation aus Tribes, Squads und Chaptern versteht, ist sie dort jahrelang im Einsatz gewesen (siehe hier ab Minute 28). Als Blaupause gedacht war sie nie, funktionieren kann sie trotzdem.

LeSS ist das beste agile Skalierungs-Framework

Was steckt dahinter? Erneut die Ablehnung übermässiger Prozesslastigkeit, die in den meisten Skalierungen anzutreffen ist. Das Versprechen von LeSS, Scrum ohne zusätzliche Meetings skalieren zu können, wirkt im Vergleich sehr verlockend.

Was ist davon zu halten? Erneut: es kommt darauf an. Wenn die beteiligten Teams mit einem gemeinsamen Ziel an einem gemeinsamen Produkt in einem gemeinsamen System arbeiten sind LeSS (oder Nexus) sehr zu empfehlen, bei anderen Konstellationen können andere Ansätze besser passen.

Es gibt einen agil-industriellen Komplex

Was steckt dahinter? Die Erkenntnis, dass es einem Grossteil der Schulungs- und Zertifizierungs-Anbieter vor allem um ein sicheres Business Model geht und weniger um bessere Produkte und flexiblere Prozesse, weshalb mitunter auch unnötige Kurse und Zertifikate verkauft werden.

Was ist davon zu halten? Über das Wording kann man streten, aber das Phänomen ist real. Es gibt eine Schulungs- und Zertifizierungs-Industrie in der aufgrund systemischer Zusammenhänge teure Prüfungs- und Teilnahmebescheinigungen zum Selbstzweck geworden sind.

Die Liste liesse sich sicher noch erweitern, die grundlegende Stossrichtung dürfte aber klar sein, genau wie die sich daraus ergebende Problematik. (Agiles) Virtue Signaling wirkt bewusst polarisierend und z.T. ausgrenzend, zudem beansprucht es die Deutungshoheit über richtig und falsch. Das Führen differenzierter und konstruktiver Diskussionen ist auf dieser Basis sehr schwierig, mit grosser Wahrscheinlichkeit wird diese Art der Gesprächsführung in Konflikten enden (oder in Group Think).

Um die (ja grundlegend richten) Ausgangsüberlegungen besser zu vertreten bieten sich daher andere Vorgehensweisen eher an. Kritischer Rationalismus, Prime Directive und Datengetriebene Validierung lassen sich zwar nicht mit vergleichbarer Emotionalität vertreten, aber genau das ist am Ende auch der Punkt: wer in einer ungewissen und wechselhaften Umgebung versucht bestimmte Ideen als richtig und falsch zu kategorisieren mag sich zwar moralisch überlegen fühlen, der Realität gerecht werden wird er aber eher nicht.

Bild: Pexels / Fauxels - Lizenz

Zu den spannenden Fragen im Umfeld der stark auf selbstorganisierte Teams setzenden agilen Frameworks gehört diese: warum ist es vor allem in der Software-Entwicklung zu ihrer starken Verbreitung gekommen, während sie in anderen Branchen bisher eher Ausnahmeerscheinungen sind? Natürlich gibt es Erklärungsansätze, die aber meistens von der selben Prämisse ausgehen - der Komplexität des Arbeitsgegenstandes. Möglicherweise ist der Grund aber ein ganz anderer.

Zum besseren Verständnis kurz eine Erklärung der Arbeitsgegenstand-Hypothese. Sie beruht darauf, dass es sich bei der Softwareentwicklung um eine komplexe Tätigkeit handelt, also um eine, bei der Kleinteiligkeit, Vernetztheit und Volatilität dafür sorgen, dass ständig Neu- und Umgeplant werden muss. Da zentrale Befehls- oder Koordinations-Instanzen dabei zu verlangsamenden Flaschenhälsen werden können, wird angenommen, dass Selbstorganisation die logische Folge ist.

Was diese Annahme in Frage stellt ist ein Blick auf andere komplexe Arbeitskonstellationen. Z.B. unterliegen auch Filmproduktionen, Nachrichtenredaktionen und Spitzengastronomie den Faktoren Kleinteiligkeit, Vernetztheit und Volatilität, trotzdem ist Selbstorganisation in ihnen eher selten. Regelmässig aufkommende Skandale zeugen sogar vom Gegenteil: Macht-Zentralisierung (und Machtmissbrauch) sind weit verbreitet und werden stillschweigend geduldet.

Der zentrale Unterschied, der die IT-Branche von den gerade genannten (und vielen anderen) Branchen unterscheidet, ist der Fachkräftemangel. Während es auf dem Arbeitsmarkt ein deutliches Überangebot an Schauspielern, Kameraleuten, Journalisten und Köchen gibt, sind Softwareentwickler selten und schwer zu kriegen. Und selbst dort, wo es gelingt die freien Stellen zu besetzen, geschieht das häufig nur durch externe Dienstleister und Freiberufler.

Die sich daraus ergebenden Folgen kann sich jeder vorstellen: wer froh sein muss, einen von wenigen gut bezahlten Jobs ergattert zu haben, wird gegenüber seinem Vorgesetzten ein eher unterwürfiges Verhalten an den Tag legen, um ihn möglichst lange ausüben zu können. Und das sogar dann, wenn die Behandlung die man erfährt bestimmend, micro-managend oder sogar missbrauchend ist (in den oben verlinkten Artikeln sind z.T. verstörende Details zu lesen).

Umgekehrt wird jemand der nicht nur in kurzer Zeit sondern auch in der näheren Umgebung jederzeit eine neue, gleich gut bezahlte Anstellung finden kann, sich wenig gefallen lassen und im Zweifel durch eine Abstimmung mit den Füssen dafür sorgen, dass dominante Vorgesetzte bald niemanden mehr haben, den sie im Detail managen können. Und da jeder Manager das weiss wird er seinen Untergebenen bereits vorauseilend möglichst grosse Freiheiten gewähren.

Auch im Rahmen grosszügig gewährter Freiheiten muss aber sichergestellt sein, dass Kunden- und Unternehmens-Interessen und Gesetze gewahrt werden. Und da eine Erzwingung von oben die kostbaren Fachkräfte verschrecken könnte, ist die Gewährung von Selbstorganisation oft der beste Weg um zur Einhaltung dieser Vorgaben zu kommen - ihre Umsetzung wird einfach in die Verantwortung von selbstorganisierten Teams übergeben.

Um Missverständnisse zu vermeiden: damit soll nicht gesagt sein, dass die Annahme falsch ist, dass komplexe Herausforderungen am besten durch selbstorganisierte Teams gemeistert werden können. Vieles spricht dafür, dass das tatsächlich der Fall ist. Der tatsächliche Grund für die Zulassung und Förderung von selbstorganisiertem Arbeiten ist aber sehr oft eher darin zu finden, dass Jobs in den Mangelberufen der IT attraktiv ausgestaltet werden sollen.

Grafik: Wikimedia Commons / Daniel Penfield - Public Domain

Dritter Teil der Übersicht über die Lean-Metriken. Nach einer allgmeinen Übersicht über die Typen von Durchlaufzeiten im ersten Teil (zu finden hier) und die einer Einführung in die Flusseffektivität im zweiten Teil (zu finden hier) soll es heute um die Flusseffizienz gehen. Um diese ähnlich klingenden Begriffe zu unterscheiden: während es bei der Effektivität darum geht die eigenen Tätigkeiten auf Sinnhaftigkeit zu optimieren (→ wenig Waste) hat Effizienz die Leistungsfähigkeit als Ziel (→ hoher Ausstoß). Zu beachten ist dabei natürlich, dass beides angestrebt werden sollte, hier soll es aber jetzt nur um Metriken für die Flusseffizienz gehen.

Takt Time

Die Takt Time bezeichnet die (anzustrebenderweise) immer gleich bleibende Zeit die zur Fertigstellung eines Liefergegenstandes benötigt wird, beispielsweise die 30 Sekunden die für einen Stanz- oder Fräs-Vorgang nötig sind. Eine der Lean-Metriken die nur schwer in die Software-Entwicklung übertragbar sind, wenn überhaupt eher auf automatisierte Prozesse als auf Programmiertätigkeiten.

Throughput Time

Auf Deutsch der Durchsatz. Bei ihm wird nicht mehr die Dauer einzelner Arbeitsvorgänge gemessen, sondern die Anzahl der erzeugten Ergebnisse (Produkte, Features, etc.) pro Zeiteinheit. Ein Beispiel wären 500 Autos die pro Tag in einer Fabrik gebaut werden. Aus dem Versuch die Throughput-Messung in die Software-Enwicklung zu übertragen ist das Konzept der Velocity entstanden.

Maintenance Time

Eine Metrik die leicht für einen Teil der Blocked Time gehalten werden kann, da Maintenance (Wartung) ähnlich wie diese dafür sorgt, dass die eigentliche Arbeit nicht stattfinden kann. Die Differenzierung: statt die Gesamtzeit der Nichtverfügbarkeit zu messen geht ist hier um die Durchschnittsdauer eines Wartungsintervalls, die idealerweise möglichst kurz sein sollte.

Recovery Time

Dieser Metriken-Typ ist von Bedeutung wenn es trotz Wartungen zu unfallbedingten Ausfällen kommt und misst die Durchschnittsdauer der Reparaturen und und der anschliessenden Wiederinbetriebnahme. Diese Dauer möglichst kurz zu halten ist nochmal wichtiger als bei der Maintenance Time, da das Eintreten von Zwischenfällen und Recovery-Phasen meistens unvorhersehbar und nicht planbar ist.

Flusseffizienz

Sowohl in Bezug auf die Produktion von Ergebnissen (Produkte, Features, etc.) als auch in Bezug auf Wartungen und Wiederinbetriebnahmen ist es das Ziel, die durchschnittliche Erstellungs- oder Bearbeitungszeiten so kurz wie möglich zu halten. Mit Hilfe der hier genannten Metriken darauf zu optimieren ermöglicht eine höhere Effizienz im Arbeitsfluss, die aber nicht ohne Risiko ist.

Eine ausschliessliche Fixierung auf Flusseffizienz macht vor allem in der Serienfertigung Sinn, in der Produktentwicklung besteht das Risiko, dass man in der Build Trap landet, also versehentlich das Falsche produziert, davon aber sehr schnell sehr viel. Hier solte also regelmässig überprüft werden, ob man noch immer in der richtigen Richtung unterwegs ist.

Bild: Pixabay / Robin Higgins - Lizenz

Um es vorwegzunehmen: ich bin grosser Fan von Scrum im Allgemeinen und von der Rolle des Scrum Masters im Besonderen. Wie aber bei allen guten Ideen gibt es aber leider auch hier die Möglichkeit, sie so umzusetzen, dass sie eher schadet als nützt. Das kann schon bei der Ausgestaltung und Besetzung der Rolle beginnen (siehe hier), es kann aber auch sein, dass der Rollen-Inhaber sich (ggf. unbewusst) kontraproduktiv verhält. Um einen solchen Fall soll es hier gehen.

Ein Verhaltensmuster, das immer wieder zu beobachten ist, ist dass der Scrum Master bestimmte Tätigkeiten auf sich monopolisiert. Das kann auf den ersten Blick sinnvoll erscheinen, da die Absicht dahintersteckt das Team zu entlasten oder zu beschützen, im Ergebnis führt ein solches Verhalten aber meistens zu Flaschenhälsen in der Kommunikation, zu Unselbstständigkeit des Teams und zur Errichtung von Barrieren zwischen Menschen die eigentlich zusammenarbeiten sollten.

Der Klassiker unter diesen Monopolisierungen betrifft die Moderation der Meetings. Obwohl im Scrum Guide nicht vorgegeben ist, wer die Moderatoren-Rolle einzunehmen hat, wird sie in gefühlt 99 Prozent der Fälle vom Scrum Master übernommen. Dafür gibt es auch Gründe (der einfachste ist der, dass er es am besten kann), die Konsequenz ist aber häufig, dass in seiner Abwesenheit die Termine ausfallen, unstrukturiert ablaufen oder einen externen Moderator brauchen. Alles nicht im Sinn der Idee.

Ebenfalls problematisch ist die Monopolisierung des Impediment-Lösens. Auch hier ist die Absicht meistens eine gute: die anderen Teammitglieder sollen sich auf ihre Arbeit konzentrieren können und für die Stakeholder soll ein durchgehender Ansprechpartner da sein. Das Ergebnis sind aber häufig stille Post-Effekte und verlangsame Kommunikation, da die von Problemen betroffenen Personen und die, die es lösen können nicht mehr in direktem Kontakt sind.

Ein dritter Problemfall tritt auf, wenn die Koordination zwischen den Teams vor allem über deren Scrum Master läuft, z.B. wenn nur sie an einem Scrum of Scrums teilnehmen, neben dem es keine anderen gemeinsamen Kommunikations-Gelegenheiten gibt. Stille Post-Effekte und verlangsame Kommunikation sind auch in diesem Fall wahrscheinlich und werden oft dadurch verstärkt, dass die Scrum Master keinen technischen Hintergrund haben.

Die Lösung für diese (und viele weitere) Probleme ist es, gezielt nach den Themen zu suchen, die bisher ausschliesslich beim Scrum Master liegen und dafür zu sorgen, dass auch andere Mitglieder des Scrumteams Übung darin bekommen, sie zu übernehmen. Das ist am Einfachsten möglich bei der Meeting-Moderation, relativ einfach bei den teamübergreifenden Abstimmungen und am schwierigsten bei der Impediment-Lösung. Möglich ist es aber in allen Fällen.

Zuletzt noch zu möglichen Gegenargumenten. Anders als häufig angenommen wird gibt der Scrum Guide nicht vor, dass bestimmte Themen ausschliesslich dem Scrum Master zugeordnet sind. Um die häufigsten Missverständnisse zu nennen - "ensuring that all Scrum events take place" bedeutet eben nicht, dass er sie alle moderiert (im Daily ist nichtmal seine Anwesenheit nötig), und "causing the removal of impediments" bedeutet eben nicht, dass er sie alle selbst beseitigt.

Auch das Argument, dass die Übernahme von Meeting-Moderation, Impediment-Lösungen und übergreifender Kommunikation die Team-Mitglieder von ihrer "eigentlichen Arbeit" abhält, ist mindestens fragwürdig. In Scrum sind "self-management and cross-functionality" explizit für das gesamte Team vorgesehen, eben um zu verhindern, von einzelnen Personen abhängig zu sein. Die (scheinbaren) Scrum Master-Aufgaben zu übernehmen gehört also explizit zur Arbeit dazu.

Natürlich muss man diese Ansichten nicht teilen, man kann auch der Meinung sein, dass es effizienter oder effektiver ist, derartige Aufgaben vom Team fernzuhalten. Der Punkt ist aber: selbst wenn man das aus dem besten Willen heraus tut, wird man sehr schnell in einen Widerspruch zu den Regeln von Scrum geraten. Und jemand, der die Regeln von Scrum unterläuft oder aufhebt, ist per Definiton ein Impediment, selbst dann wenn diese Person der Scrum Master ist.

Ich bin mir ziemlich sicher, dass ich irgendwann mal etwas über das Arisoteles-Projekt von Google geschrieben habe, eine Studie mit 180 teilnehmenden Teams, deren Ergebnis war, dass Hochleistung vor allem dann möglich ist, wenn die folgenden Dinge gegeben sind: Psychologische Sicherheit, Verlässlichkeit der Kollegen, Struktur und Klarheit der Ziele, Sinnhaftigkeit der Arbeit und Selbstwirksamkeitserwartung. Ich finde meinen Text gerade nicht, daher ist es um so besser, dass Talia Lancaster einen Vortrag zu dem Thema gehalten hat, den man sich ansehen kann.

Der Vortrag fasst dabei nicht nur die Ergebnisse des Aristoteles-Projekts zusammen, sondern zeigt auch auf wie im eigenen Unternehmen überprüft werden kann ob die verschiedenen Faktoren gegeben sind. Man kann sich also direkt für eine eigene Anwendung inspirieren lassen.