On Lean and Agility

Bild: Unsplash / Austin Distel -

Für viele Scrum Master oder Scrum Teams ist die Frage nach dem wichtigsten Scrum-Meeting schnell beantwortet: die meisten werden schnell die Retrospektive nennen, die in der Regel als das Inspect & Adapt-Event schlechthin gesehen wird. Ein nennenswerte Minderheit dürfte eher zum Daily Scrum tendieren, in dem auf tagesaktueller Basis der Arbeitsfortschritt besprochen wird. Ich dagegen würde ein drittes Meeting als das wichtigste bezeichnen: das Sprint Review.

Um zu verstehen wie ich dazu komme besinnen wir uns kurz auf etwas Grundlegendes: der einzige Existenz-Zweck eines Scrum Teams ist die Lieferung von benutzbarem Mehrwert für ein Markt- oder Kundensegment. Alle anderen üblicherweise angestrebten Ziele (schlanke Prozesse, schnelle Reaktionsfähigkeit, technische Exzellenz, psychologische Sicherheit, etc.) sind nur Mittel um dieses Haupt-Ziel zu erreichen denn nur dieses Hauptziel sichert das wirtschaftliche Überleben.

Die Überprüfung, ob auf dieses Hauptziel noch immer hingearbeitet wird könnte nun theoretisch in jedem der Scrum Meetings stattfinden. Im Planning sollten nur wertstiftende Sprintziele eingeplant werden, im Daily sollte sichergestellt werden, dass nur auf dieses Ziel hingearbeitet wird, in der Retrospektive kann daran gearbeitet werden, all das nochmals zu optimieren. Eines aber ist in all diesen Meetings nicht möglich: zu überprüfen, ob wirklich Wert geschaffen wird.

Der Grund dafür ist einfach: in allen Regel-Meetings (mit der einen Ausnahme des Sprint Reviews) sind die meisten Scrum Teams unter sich. Ob tatsächlich etwas Wertschöpfendes geplant und geschaffen wird, sehen sie dort nur aus ihrer subjektiven Perspektive - und schlimmstenfalls ist die verfälscht, durch Group Think, Betriebsblindheit, Confirmation Biases und andere Antipattern. Derartige Teams bauen ihr Produkt de facto nur noch für sich, und oft genug an ihrer Zielgruppe vorbei.

Um es dazu nicht kommen zu lassen hilft nur eines: die eigene Filterblase regelmässig platzen lassen und den Kontakt mit der echten Welt da draussen suchen. Nur echte Kunden (und wenn die nicht greifbar sind dann wenigstens echte Kundenservice- oder Vertriebsmitarbeiter) können wirklich sagen, ob eine Nutzungs- und/oder Kaufbereitschaft für das erstellte Produkt besteht. Und diese echten Kunden oder Kundenvertreter trifft das Scrum Team eben im Sprint Review, das darum das wichtigste Meeting ist.

Das heisst natürlich nicht, dass die anderen Scrum Meetings unwichtig sind, im Gegenteil. Jedes von ihnen erfüllt einen bestimmten und entscheidenden Zweck. Aber in Relation zum Sprint Review und seiner für die Validierungs des Existenzwecks des Team elementaren Funktion treten sie alle ein Stück in den Hintergrund. So zumindest meine Meinung, die ich schon seit Jahren und in jeder sich bietenden Diskussion gerne verteidige.

Der Vollständigkeit halber sei natürlich erwähnt, dass es in Scrum theoretisch auch noch andere Möglichkeiten gibt, durch Zielgruppen- oder Stakeholder-Einbindung aus der eigenen Filterblase herauszukommen. Mehr dazu hier. Aber nach über 10 Jahren in zig Unternehmen traue ich mir die Aussage zu, dass das nur in sehr, sehr wenigen Teams stattfindet. Warum auch immer.

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf¹). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

Unter den agilen Frameworks ist LeSS (Large Scale Scrum) vermutlich das mit der kuriosesten Entstehungsgeschichte. Ursprünglich entwickelt um das eigentliche Scrum ohne inhaltliche Veränderungen in Skalierungs-Kontexte übertragen zu können, haben sich seine Urheber gegen 2017 entschlossen, sich vom original-Scrum abzukoppeln und ihre eigene, inhaltlich abweichende Version zu entwickeln. Diese Entwicklung ist seit Juli 2024 abgeschlossen, es gibt jetzt einen "LeSS Scrum Guide".

• Scrum Guide (offizielle Version)
  
• Scrum Guide (LeSS Version)

Die Abweichungen zum offiziellen Scrum Guide lassen sich dabei in zwei Kategorien einteilen: zum einen sind es Themen, zu denen die LeSS-Erfinder Craig Larman und Bas Vodde eine andere Meinung haben als die Scrum-Erfinder Jeff Sutherland und Ken Schwaber, zum anderen sind es redaktionelle Änderungen, die den formalen Aufbau des Scrum Guides (Reihenfolge und Gruppierung der Themen) verändern, inhaltlich aber alles beim Alten lassen.

Bei der ersten Kategorie, den inhaltlichen Abweichungen, ist vor allem das (Development-) Team zu nennen. Aus dem offiziellen Scrum wurde es 2020 entfernt und durch "the Developers" ersetzt, um zu verhindern, dass ein Teil-Team innerhalb des Scrum Teams entsteht, dem Product Owner und Scrum Master nicht angehören. LeSS geht in die andere Richtung - diese beiden Rollen sind hier ausserhalb der Teams auf einer übergreifenden Ebene (und nehmen dadurch z.B. auch nicht an den Retrospektiven teil).

Die zweite wichtige Abweichung ist das Zielbild: im offiziellen Scrum findet sich seit 2020 das übergreifende Product Goal, zu dessen Eigenschaften gehört, dass es erreicht und abgeschlossen werden kann (es kann danach ggf. durch ein neues ersetzt werden). Abweichend davon gibt es in LeSS die Product Vision, die deutlich abstrakter ist. Als Folge dessen ist ein abschliessendes Beenden der Arbeit am Product Backlog hier ausdrücklich nicht vorgesehen (und wird sogar explizit ausgeschlossen).

Die dritte Abweichung dreht sich um das Backlog Refinement. Im offiziellen Scrum ist es eine durchgehend stattfindende Tätigkeit, deren Anlass, Umfang und Teilnehmer nicht erwähnt werden. In LeSS ist es abweichend davon als optionales Meeting beschrieben, einschliesslich der Teilnehmer (Scrum-Rollen und ggf. Stakeholder), des Ablaufs und des möglichen Umfangs (maximal 10 Prozent des Sprints, eine Regel, die 2020 aus dem offiziellen Scrum Guide entfernt wurde).

Darüber hinaus gebt es verschiedene weitere, eher abstrakte Abweichungen. Beispielsweise enthält das Product Backlog im offiziellen Scrum "Work for a complex Problem", in LeSS dagegen "Ideas for incrementally creating a Product"; Scrum basiert laut offiziellem Scrum Guide auf "Empiricism and Lean Thinking", laut LeSS-Scrum Guide dagegen nur auf "Empiricism"; die Definition of Done ist offiziell ein Committment, in LeSS dagegen ein Agreement. Den meisten Lesern dürfte das kaum auffallen.

Die zweite Kategorie der Abweichungen des LeSS-Scrum Guide zum offiziellen Scrum Guide sind die redaktionellen Änderungen. Der Sprint steht nicht mehr im Abschnitt der Events (Meetings) sondern hat einen eigenen Abschnitt, die drei im Sprint Planning zu beantwortenden Fragen sind nicht mehr nummeriert, etc. Das Ziel ist vermutlich eine bessere Lesbarkeit und Verständlichkeit, erklärt werden die Gründe für diese Neuformatierung nicht näher.

Soviel zum Inhalt, als nächstes drängt sich die Frage auf: braucht denn irgendjemand diesen zweiten Scrum Guide? Aus Sicht der LeSS-Erfinder bestimmt, zumindest dann, wenn man ihr Framework anwendet, in dessen Rahmen mehrere Entwicklungsteams sich einen Product Owner und ein Product Backlog teilen. Aus einer Scrum-puristischen Sicht vermutlich eher nicht, alleine deshalb nicht, weil diese Skalierungs-Praktiken seit 2020 auch (optionale) Teile des offiziellen Scrum sind.

Am Ende wird jedes Unternehmen oder jedes Team selber entscheiden müssen, welchen der beiden Scrum Guides es besser findet und welchen nicht. Erfahrungsgemäss dürfte das in den meisten Fällen aber eine relativ nachrangige Frage sein. In der Praxis werden die Umsetzungen der beiden Varianten (wenn sie denn wie vorgegeben stattfinden) sich ohnehin nur durch Methoden-Experten unterscheiden lassen und sich für die Beteiligten gleich anfühlen.

Was auf jeden Fall kritisch anzumerken ist, ist, dass LeSS durch diesen neuen Guide in sich selbst inkonsistent wird. Auf der offiziellen Website LeSS.works findet sich zum Beispiel in der offiziellen Beschreibung des LeSS-Frameworks noch ein aus zwei Teilen bestehendes Planning, im LeSS-Scrum Guide sind es drei. In der Framework-Beschreibung wird von teambasierten Refinements abgeraten, im LeSS-Scrum Guide sind sie enthalten. Da muss noch aufgeräumt werden.

Zuletzt eine Beobachtung: im Abschnitt Purpose of the Scrum Guide haben die LeSS-Erfinder Larman und Vodde eine Spitze gegen Jeff Sutherland untergebracht - der offizielle Scrum Guide wird hier bezeichnet als "the Scrum Guide by Ken Schwaber". Das ist zwar nicht komplett falsch, dass Sutherland an der letzten Version nicht beteiligt war, ist offiziell bestätigt worden. Seinen Beitrag komplett unter den Tisch fallen zu lassen ist aber zumindest ungewöhnlich, wer weiss was da im Hintergrund passiert ist.

Bild: Pexels / Zen Chung - Lizenz

Zu den Mythen, die sich mit der Zeit um das Scrum-Framework gebildet haben, gehört der, dass der Scrum Master sich mit der Zeit selber überflüssig macht und irgendwann nicht mehr benötigt wird. Auf den ersten Blick erscheint das auch wie eine naheliegende Idee, bei näherer Betrachtung hat sie aber durchaus problematische Aspekte. Es lohnt sich, näher zu betrachten wo diese Aussage herkommt, wie sie gemeint ist und was für Folgen sie haben kann.

Um mit dem Einfachsten zu beginnen: in keinem der offiziellen Scrum-Dokumente befindet sich eine auch nur entfernt ähnliche Aussage. Weder in der aktuellen Version des Scrum Guide, noch in einer der älteren Versionen, noch in einem der Konferenz-Papers mit denen Ken Schwaber und Jeff Sutherland ihren Ansatz am Anfang bekannt gemacht haben ist die Rede davon, dass der Scrum Master irgendwann nicht mehr gebraucht werden könnte (wer nachlesen will - hier sind alle dieser Dokumente verlinkt).

Der Urheber ist also irgendjemand, der nicht an der Entwicklung von Scrum beteiligt war, überspitzt könnte man sagen: ein Mensch mit einer starken Privat-Meinung. Wer genau das gewesen ist, lässt sich wahrscheinlich nicht mehr rekonstruieren, man kann aber zumindest sagen, wer diese Idee vermutlich bekannt gemacht und popularisiert hat - Geoff Watts, ein bekannter englischer Scrum Master, in seinem 2013 erschienen Buch Scrum Mastery: From Good To Great Servant-Leadership.

My second piece of advice is to go into the role of ScrumMaster with the intention of making the role of ScrumMaster for this team unnecessary. Create such a high-performing, self-organising team, with such a good relationship with the product owner, with such a keen understanding of the Scrum framework (and the principles behind the framework) that they don’t need any facilitation (of either process or people) and have no impediments left to remove. In other words, be so great that they don’t need you anymore. I’m not saying this will definitely happen, but the more you aim for it, the more quickly your team will develop and the better your team will perform.

Geoff Watts: Scrum Mastery (2.Auflage), S.27

Wie man aus diesem Abschnitt herauslesen kann, beschreibt Watts ein Idealbild, dessen Erreichung eher unwahrscheinlich ist. Das tatsächliche Ziel ist dabei weniger die Selbstabschaffung sondern die konstante Arbeit daran, das Scrum Team selbstorganisiert zu machen und ihm diese Selbstorganisation zu erhalten. Indirekt wird gleichzeitig vor dem häufigen Antipattern gewarnt, bestimmte Tätigkeiten in der Scrum Master-Rolle zu monopolisieren (was andere negative Folgen mit sich bringen würde).

Dass das Idealbild eines Scrum Teams ohne Scrum Master nur schwer zu erreichen ist, hat übrigens handfeste Gründe: Vieles von dem, was in dieser Rolle gemacht wird, erfordert ein Heraustreten aus den Alltagsabläufen und eine Konzentration auf langfristige Ziele. Da gerade in Scrum mit seinen kurzen Sprints aber ein permanenter kurzfristiger Lieferdruck herrscht, wäre eine Verdrängung der Langfrist- durch die Kurzfrist-Ziele hochwahrscheinlich, wenn sie von den selben Personen verantwortet werden (kurzfristige Verpflichtungen fühlen sich immer dringender an als langfristige).

Gleichzeitig ist es eine wichtige Eigenschaft des Scrum Masters, überparteilich zu sein, um bei Konflikten (z.B. zwischen den Entwicklern oder zwischen Product Owner und Stakeholdern) vermitteln zu können.¹ Ohne ihn fällt diese Vermittlerrolle weg, und wird aufgrund des fehlenden Kontextwissens nur eingeschränkt durch einen externen Moderator oder Mediator ersetzt werden können. Schlimmstenfalls kommt es nur zu Schein-Konsensen, oder solchen die nicht lange halten.

Trotz dieser Faktoren wäre das Setzen des Scrum Master-Selbstabschaffungs-Ziels zunächst unproblematisch, da es aufgrund seiner Langfristigkeit kaum ins Gewicht fällt, wenn es auf absehbare Zeit nicht erreicht wird. Zu einem Problem wird es aber, wenn dieses Ziel in die Einsatz- und Budgetplanungen integriert wird. Und vor allem grosse Firmen versuchen genau das immer wieder, was verschiedene problematische Folgen mit sich bringt.

Zum einen werden in vielen Fällen keine internen Scrum Master-Positionen geschaffen, da man die ja "nur vorübergehend braucht". Das schwächt diese Rolle, es sorgt für eine hohe Fluktuation (aus Sorge vor Scheinselbstständigkeit sind externe Besetzungen meistens befristet) und macht sie zu einem primären Ziel von Sparprogrammen, da der Abbau von externem Personal einer der einfachsten und schnellsten Wege ist, um Kosten (scheinbar) zu senken.

Zum anderen führt auch bei internen Scrum Mastern die Idee, dass diese irgendwann überflüssig werden, zu "Optimierungsversuchen". Eine immer wieder anzutreffende Variante ist die Deckelung der Zeit, in der ein Team Anspruch auf diese Rolle hat (z.B. auf ein Jahr), eine andere besteht daraus, dass sie ab dem Überschreiten bestimmter Zeiträume nur noch in Teilzeit zur Verfügung steht, um in der restlichen Zeit ein weiteres Team übernehmen zu können (und irgendwann zwei weitere, und drei, etc.).

Beide Varianten führen dazu, dass sowohl die Teams als auch die Scrum Master unter einen permanenten Rechtfertigungsdruck gesetzt werden und immer wieder erklären müssen, warum sie das Selbstorganisations-Ziel noch immer nicht erreicht haben. Das zieht kontinuierlich Zeit und Energie von den wichtigen Aufgaben ab (und was passiert, wenn das Ziel, ohne Scrum Master klarzukommen, mit einem Gehaltsbestandteil verbunden wird - man kann es sich denken. Nichts Gutes jedenfalls).

Zusammengefasst: das Ziel, dass der Scrum Master sich selbst überflüssig macht, ist kein offizieller Teil von Scrum, und es ist nie ein Teil davon gewesen. Dort wo es propagiert wird, wird es als ein kaum zu erreichender Idealzustand verstanden, das eigentliche Ziel ist ein ganz anderes. Und dort wo es missverstanden wird oder den falschen Menschen in die Hände fällt, kann es Fehler im Systemdesign, Ressourcenverschwendung und ständigen Stress zur Folge haben.

Das alles ist wirklich schade, da die Grundidee eigentlich gut und erstrebenswert klingt. Aufgrund der damit verbundenen Risiken sollte man es sich allerdings mehrfach überlegen, bevor man sie in der eigenen Firma äussert. Im Zweifel startet man dadurch eine Dynamik, die sich nur schwer wieder einfangen lässt und ohne Notwendigkeit Konflikte verursacht.

Bild: Pexels / Theo Decker - Lizenz

Auf die Frage nach den Rollen, bzw. Verantwortlichkeiten, in Scrum werden die meisten Kenner dieses Frameworks ohne zu Zögern mit den Entwicklern, dem Product Owner und dem Scrum Master antworten. Das ist auch grundsätzlich richtig, lässt aber eine vierte aus, die im Scrum Guide (Version von 2020) immerhin dreizehn mal an verschiedenen Stellen genannt wird: die der Stakeholder, also der (team-externen) Interessenvertreter. Wie kommt es, dass diese Gruppe so häufig übergangen wird?

Eine Antwort darauf ist, dass die Stakeholdern im Scrum (scheinbar) nicht am Sprint beteiligt sind. Bei oberflächlicher Betrachtung kann es so erscheinen, als würden sie nur als "Publikum" im Sprint Review erscheinen. Bei näherer Betrachtung können sie aber durchaus stärker eingebunden werden. Zum einen aufgrund der Vorgaben des Scrum Guide selbst, zum anderen durch verschiedene Praktiken, mit denen die bewusst offen gelassenen Lücken von Scrum gefüllt werden können.

Die Stakeholder im Sprint Planning

Um mit einer kleinen Überraschung zu starten - die mögliche Mitwirkung der Stakeholder im Planning steht im Scrum Guide. The Scrum Team may also invite other people to attend Sprint Planning to provide advice. heisst es dort. Eine Möglichkeit, von der viel zu selten Gebrauch gemacht wird.

Die Stakeholder im Daily Scrum

Es ist kein offizieller Teil von Scrum, aber eine häufige Praxis: Daily Scrum Meetings finden öffentlich statt, so dass jeder, der ein Interesse hat, als Zuschauer teilnehmen kann. Häufig reicht das bereits als ein Kommunikationsinstrument aus, ggf. ergeben sich daraus auch Themen für Folgegespräche.

Die Stakeholder im Backlog Refinement

In Scrum ist das Refinement nicht notwendigerweise ein Meeting sondern eine Tätigkeit, in deren Rahmen Backlog-Einträge erstellt, präzisiert und priorisiert werden. Analog zum Sprint Planning können dabei Experten und Kundenvertreter bei Bedarf einbezogen werden.

Die Stakeholder in der Sprint Review-Vorbereitung

Nirgendwo steht, dass die Stakeholder erst im Review-Meeting die Sprint-Ergebnisse sehen dürfen. Oft gilt sogar ein je früher, desto besser, da dadurch mehr Zeit bleibt die Features auszuprobieren, Feedback vorzubereiten und, falls die Zeit das zulässt, sogar noch Änderungswünsche zu platzieren.¹

Die Stakeholder im Sprint Review

Nochmal zum Scrum Guide. Ihm zufolge wird den Stakeholdern im Review nicht nur das Ergebnis gezeigt und sie geben nicht nur Feedback, sie erarbeiten darüber hinaus zusammen mit dem Scrum Team nächste Schritte und passen gemeinsam die Planung an. Es ist eine aktive, mitentscheidende Rolle.²

Die Stakeholder in der Sprint Retrospektive

Der seltenste Beteiligungsfall: Retrospektiven sind im Normalfall strikt Scrum Team-intern, um dort vertraulich und in psychologischer Sicherheit auch an schwierigen Themen arbeiten zu können. Aber wenn es dabei um die Zusammenarbeit mit Anderen geht, können die auch gezielt eingeladen werden.

Spezielle Stakeholder-Termine

Über die offiziellen Scrum-Events hinaus kann es Sinn machen, weitere Stakeholder-Termine einzurichten. Welche das sind kann je nach Bedarf unterschiedlich sein, es sollten nur nicht zu viele werden. Und übrigens: auch das Scrum of Scrums ist bei näherer Betrachtung ein Stakeholder-Meeting.

Noch einmal zusammengefasst: wer in den Stakeholdern nur das Publikum für die Sprint Reviews sieht, wird nicht das volle Potential von Scrum nutzen. Sie können (und sollen) an verschiedenen Stellen ihre Expertise einbringen und in diesem Rahmen aktiv mit den drei anderen Rollen, bzw. Verantwortlichkeiten, zusammenarbeiten. Und dort wo das noch nicht passiert sollte der Scrum Master tätig werden. Zu dessen Aufgaben gehört nämlich laut Scrum Guide removing barriers between stakeholders and Scrum Teams.

Noch einmal zum Thema Velocity. Obwohl diese Metrik kein offizieller Teil von Scrum ist, ist sie in vielen Teams ein wesentliches Element der Umsetzung dieses Frameworks. Was dabei im Mittelpunkt steht, ist in der Regel der Planungs-Aspekt, also die Ableitung zukünftiger Arbeitsleistung aus der durchschnittlichen Story Point-Menge der letzten Sprints (siehe hier). Es gibt aber auch einen zweiten, seltener thematisierten Aspekt: eine Velocity erzeugt auch ein Work in Progress Limit (WIP Limit).

WIP Limits kennt man eigentlich aus Kanban und anderen Lean-Ansätzen, wo sie verwandt werden, um Überlastung und Multitasking zu vermeiden und den Arbeitsfluss zu verbessern. Die Idee ist eigentlich einfach: dadurch, dass eine Obergrenze für gleichzeitig bearbeitete Aufgaben eingeführt wird, werden weniger Arbeitspakete gleichzeitig begonnen, Multitasking und Koordinationsaufwände gehen zurück und Ergebnisse werden schneller fertig.

Das klingt erstmal gut, in der Realität kommt es allerdings regelmässig dazu, dass diese Obergrenzen zu hoch angesetzt werden. Wenn ihre Festlegung durch das Management erfolgt kann das z.B. daran liegen, dass die Kapazität der Umsetzungsebene zu optimistisch eingeschätzt wird (oft verbunden mit Wunschdenken in Bezug auf Fertigstellungstermine), oder dass möglichst vielen Stakeholdern das Gefühl gegeben werden soll, dass ihre Anliegen bearbeitet werden.

Aber auch wenn die Verantwortung für das Setzen der WIP Limits bei den jeweiligen Umsetzungsteams liegt, sind diese häufig zu hoch. Auch das kann daran liegen, dass versucht wird, möglichst viele Stakeholder zu befriedigen, mindestens genauso häufig ist aber eine unrealistisch optimistische Einschätzung der eigenen Leistungsfähigkeit oder eine Unterschätzung des mit bestimmten Tätigkeiten verbundenen Arbeitsaufwands.

Die Verwendung der Velocity sorgt dafür, dass die WIP-Obergrenzen realistischer werden. Wenn der durchschnittliche  Output der letzten Sprints (Yesterdays Weather) bei 18 Punkten liegt, und demzufolge auch maximal diese Menge für den nächsten eingeplant werden soll, dann verschwinden "politische" Handlungsmotive und unsichere Faktoren wie die Selbst- und Fremdeinschätzung der Leistungsfähigkeit eines Teams aus dem Planungsprozess. Alleine dadurch werden die Planungen besser.

Der Vollständigkeit halber sei noch angemerkt, dass Scrum Teams die Planung ihrer Sprints eigentlich nicht an einem Output (in diesem Fall der Velocity) sondern an einem Outcome orientieren sollten, also an dem fachlichen Sprint-Ziel, dessen Umsetzungsaufwand eine gewisse Variabilität haben sollte, um auf ungeplante Entwicklungen reagieren zu können. Wenn aber (warum auch immer) eher Outcome-orientiert gearbeitet wird, kann ein auf der Velocity beruhendes WIP Limit eine gute Idee sein.

Bild: Pixabay / The Real Cicero - Lizenz

Zu den am weitesten verbreiteten Missverständnissen über Scrum gehört vermutlich, dass es nur für einzelne Teams ausgerichtet wäre. Tatsächlich ist das aber falsch, der Scrum Guide ist da sehr klar: es können sich z.B. mehrere Teams einen Product Owner und ein Product Backlog teilen, ausserdem (und darum soll es hier gehen) es kann sein, dass es eine unternehmensweite Definition of Done gibt, die für alle Teams verbindlich ist.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

Scrum Guide, 2020

Aus einer Scrum-puristischen Sicht erscheint diese Regelung zunächst wie eine Zumutung, schliesslich wird durch sie massiv in die Selbstorganisation des Teams eingegriffen. Dass diese Regelung trotzdem 2013 in den Scrum Guide aufgenommen wurde und in den seitdem stattgefundenen Aktualisierungen auch beibehalten wurde, muss also gewichtige Gründe haben. Sich diese bewusst zu machen kann für Verständnis sorgen und die Akzeptanz dieser Regelung erhöhen.

Ein erster gewichtiger Grund, der vor dem Hintergrund zu sehen ist, dass Scrum bis heute vor allem in der Software-Entwicklung eingesetzt wird, ist, dass eine gemeinsame Definition of Done gemeinsame Entwicklungsstandards möglich macht. Die können aus Coding-Standards, Schnittstellen-Definitionen, Testabdeckungs-Vorgaben oder ähnlichen Regeln bestehen und dafür sorgen, dass keine Team-basierte Code-Ownership entsteht und der Code auch teamübergreifend verständlich und weiterentwickelbar ist.

Ein zweiter Grund kann sein, durch eine gemeinsame Definition of Done übergreifende Release-Prozesse zu vereinfachen. Wenn z.B. grössere Mengen an Features erst ab einem bestimmten Zeitpunkt verfügbar sein sollen (etwa dem Weihnachtsgeschäft), kann es unnötig verkomplizierend wirken, wenn diese zum Teil bereits auf Produktion verfügbar aber ausgetoggled sind und zum Teil noch in einer Staging-Umgebung warten. Das zu vereinheitlichen erleichtert Qualitätssicherung und Go Live.

Ein dritter Grund kann der sein, dass ein einheitliches Auftreten gegenüber dem Kunden sichergestellt wird. Wenn z.B. "Done" so definiert wird, dass neue Features für den Anwender benutzbar sein müssen, dann kann es sinnvoll sein, übergreifend festzulegen in welchem Ausmass auch die Aktualisierung von FAQs und Benutzer-Handbüchern dazugehört. Findet das nicht statt werden die Anwender möglicherweise unterschiedliche Beschreibungstiefen vorfinden und Frustrationserlebnisse haben.

Im Zweifel sind noch weitere Gründe vorstellbar, dass eine übergreifende Definition of Done Sinn machen kann dürfte aber klar geworden sein. Dort wo man sie einführen will sollte man sich allerdings eines Risikos bewusst sein: wenn sie alles enthält was für alle betroffenen Teams relevant ist, kann sie gross und unübersichtlich werden und ggf. dadurch noch weiter aufgebläht werden, dass in ihr beschrieben werden muss, welche ihrer Teile nur für bestimmte Teams gelten und welche nicht.

Um das zu verhindern empfiehlt es sich, den Abschnitt aus dem Scrum Guide nochmals durchzulesen. Ihm zufolge bildet die übergreifende Definition of Done nur einen Minimalteil, den die Teams individuell erweitern können. Sich auf die nur unbedingt nötigen Mindeststandards zu beschränken und alles andere den Teams zu überlassen kann daher dabei helfen, aufgeblähte Umfänge und in Einzelfällen nicht mehr überall relevante Vorgaben zu vermeiden.

Zuletzt sollte immer in Erinnerung bleiben, dass die Definition of Done eine Hilfe für die Teams bei der Erstellung ihrer Incremente ist, und nicht ein Kontroll- oder Managing-Instrument. Es macht sehr viel Sinn regelmässig nachzufragen ob das was in ihr steht von den Teams als hilfreich oder behindernd wahrgenommen wird. Und wenn letzteres der Fall ist sollte es immer möglich sein Anpassungen vorzunehmen, um erneut zu einer allgemein akzeptierten Form zu kommen.

Bild: Pexels / Diva Plavalaguna - Lizenz

Wenn irgendwo zum ersten mal Scrum eingeführt wird, kann man fast schon darauf wetten, dass man sich früher oder später eine bestimmte Beschwerde anhören kann: seit der Umstellung würde es viel zu viele Meetings geben, man käme jetzt "gar nicht mehr zum Arbeiten". Derartigen Äusserungen nachzugehen lohnt sich, schliesslich können sie schlimmstenfalls dazu führen, dass die ganze Methodik abgelehnt wird. Also: bringt Scrum zu viele Meetings mit sich?

Ein Blick in den offiziellen Scrum Guide bringt erste Erkenntnisse: in einem zweiwöchigen Sprint gibt es ein Planning von vier Stunden, ein Review von zwei Stunden, eine Retrospektive von eineinhalb Stunden und zehn Dailies von jeweils 15 Minuten. Optional kommt das Refinement dazu.¹ Im Durchschnitt kommt man damit auf ca. eine Stunde pro Tag, mit einem Schwerpunkt auf dem Sprintwechsel. Das macht noch nicht wirklich den Eindruck von Meeting-Overhead.

Dort, wo es zu einer Überhandnahme von Terminen kommt, muss es also andere Gründe geben. Einer, den man häufig findet, ist der, dass die Scrum-Meetings deutlich überzogen werden. Dailies dauern dann z.B. jeweils eine Stunde und die Retrospektive den halben Tag. Die Lösung in diesem Fall ist einfach: sich an die vorgegebenen Beschränkungen zu halten, reduziert Meeting-Zeit. Will man das nicht tun ist das zwar auch ok, dann sollte man sich aber auch nicht beschweren.²

Noch häufiger ist es so, dass sich die Meeting-Dichte dadurch ergibt, dass zu den in Scrum vorgegebenen Terminen noch weitere kommen. Dazu können Regeltermine gehören, wie z.B. wöchentliche Abstimmungen mit wichtigen Stakeholdern, aber auch anlassbezogene, z.B. Termine zur Erfassung oder Klärung von neuen Anforderungen. Es liegt damit kein Problem vor, dass sich aus der Methodik ergibt - aber eines, das sich mit Hilfe der Methodik lösen lässt.

Fast alles, was in diesen sonstigen Meetings abgehandelt wird, lässt sich auch in einem der Regeltermine unterbringen. Erfassung und Klärung von Anforderungen können im Refinement stattfinden, Stakeholder-Kommunikation im Review, Architektur-Diskussionen im Planning, eine Klärung von Unstimmigkeiten im Team in der Retrospektive. Geht man so vor gibt es kaum noch Themen, die ein zusätzliches Meeting brauchen - zumindest keine mit Bezug zum Produkt oder zum Scrum Team.

Was nämlich auch immer wieder auftritt, sind Termine völlig ohne Produkt- oder Teambezug, die zu den Scrum-Meetings dazukommen. Die können zu übergreifenden Organisationseinheiten gehören (z.B. wöchentliche Abteilungsrunden), sie können aber auch Teil des zweiten oder dritten Projekts sein, in dem einige oder alle Teammitglieder mitarbeiten müssen. Auch hier ist die Lösung einfach: man muss lediglich aufhören, die Mitarbeiter zu überplanen.

Zurück zur Ausgangsfrage: bringt Scrum zu viele Meetings mit sich? Die Antwort - ja, aber nur dann, wenn die neuen Termine die alten nicht ersetzen, sondern zu ihnen dazukommen, oder wenn für Themen, die in den bestehenden Meetings behandelt werden, könnten neue angesetzt werden. Die sich daraus ergebende gute Nachricht: man kann selbst dafür sorgen, dass der eigene Kalender leerer wird. Man muss es eben nur tun.

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.

Zu den bekanntesten Erklärvideos im Umfeld von (nicht nur) Scrum gehört Agile Product Ownership in a Nutshell, das von mittlerweile mehr als zehn Jahren von Henrik Kniberg veröffentlicht wurde. Es wurde immer wieder angemerkt, dass etwas Vergleichbares auch für den Scrum Master gut wäre. Jetzt endlich hat sich jemand der Sache angenommen:

Selbst wenn Geoff Watts, der dieses neue Video erstellt hat, einen eigenen Stil hat, passen The Scrum Master in a Nutshell und Agile Product Ownership in a Nutshell erstaunlich gut zusammen. Was jetzt noch fehlt wäre ein In the Nutshell-Video für die dritte Rolle Scrum, die Entwickler. Mal sehen wann es kommt.

Bild: Flickr / WSDOT - CC BY-NC-ND 2.0

Fragt man einen beliebigen Scrum Master aus welchen Tätigkeiten sein Beruf eigentlich besteht wird mit Sicherheit eine dabei sein: das Beseitigen von Impediments. Nachfragen was mit diesem Begriff gemeint ist führen dann aber erstaunlich häufig zu dem Punkt an dem nicht mehr näher erläutert werden kann was er bedeutet, nur dass er irgendwie alles umfasst was irgendwie problematisch ist wird meistens genannt. Dabei ist es eigentlich gar nicht so kompliziert.

Als erstes ist es wichtig zu verstehen, dass dieser Begriff oft deshalb mystifiziert wird, weil er ein eher selten vorkommendes Fremdwort ist. Englische Muttersprachler tun sich da leichter, weil es für sie ein ganz normales Wort ist - Impediment bedeutet übsetzt Hindernis oder Behinderung, und genau das ist in Scrum damit auch gemeint: irgendein Hindernis, das dazu führt, dass das von ihm betroffene Team in seiner Arbeit verlangsamt oder blockiert wird.

Auch das ist natürlich noch unkonkret, es lässt sich aber konkretisieren. Man muss sich nur fragen welche verschiedenen Kategorien von Behinderungen es geben kann von denen Teams üblicherweise betroffen sind. Aus denen ergeben sich dann auch unmittelbar die notwendigen Gegenmassnahmen, mit deren Durchführung oder Veranlassung der jeweilige Scrum Master dann (unter anderem) beschäftigt ist. Hier ist eine (sicherlich unvollständige) Übersicht:

Fehlende Personalkapazität

Einer der grossen Klassiker. Entweder sind zu wenige Leute im Team um in der gewünschten Geschwindigkeit voranzukommen oder die Teammitglieder sind nur in Teilzeit verfügbar und zum Teil an anderer Stelle verplant. In solchen Situationen ist es hilfreich den Personalverantwortlichen mit Hilfe valider Statistiken (Velocity, Lead Times, Durchschnittszeit in Meetings, etc) aufzeigen zu können, dass ohne mehr Kapazität die angestrebten Ziele nicht rechtzeitig erreicht werden können.

Fehlende Skills

Kann in verschiedenen Ausprägungen vorkommen. Entweder müssen bestimmte Tätigkeiten extern vergeben werden oder sie dauern bei interner Ausführung länger als möglich. Auch hier lässt sich das Problem mit Hilfe von Statistiken aufzeigen, sei es in Form der Wartezeiten auf externe Zulieferungen oder in Form hoher Aufwände für Analyse und Bugfixing. Beides ist normalerweise auf Dauer teurer als eine Weiterbildung oder eine Vergrösserung des Teams um Experten sein würden.

Fehlende Ressourcen

Ressourcen sind hier nicht als menschliche Mitarbeiter verstanden sondern als sonstige benötigte Mittel. Von der Entwicklungs- und Test-Umgebung über leistungsfähige Rechner, angemessene Arbeitsplätze, ausreichend vorhandene Meetingräume und Büromaterialien bis hin zu banalen aber notwendigen Dingen wie Klopapier in den Toiletten - ohne all das sind die Effektivität und Effizienz eines Teams stark eingeschränkt, was sich den Budget-Verantwortlichen in der Regel auch einfach erklären lässt.

Fehlende Genehmigungen

Von der fehlenden Genehmigung mit Kunden zu sprechen bis zur fehlenden Genehmigung auf Produktion zu deployen ist hier vieles möglich, und in der Regel wird es nicht aus bösem Willen verweigert sondern aus Angst vor Kontrollverlust. Hier sollte nicht nur aufgezeigt werden, dass Genehmigungs-Bürokratie diesen Kontrollverlust erst recht herbeiführt, sondern auch, dass Scrum mit seiner Transparenz und seiner kurzfristigem Umsteuerbarkeit sogar für mehr Kontrolle sorgen kann - wenn man die Teams machen lässt.

Falsche Priorisierungen

Selbst wenn falsch und richtig bei Backlog-Priorisierungen schwierige Begriffe sind - wenn Refactoring, Bugfixing, Testautomatisierung und Ähnliches immer wieder zugunsten neuer Features wegpriorisiert werden wird es unvermeidbar zu Problemen kommen. Die Aufgabe an dieser Stelle muss sein, dem (vermutlich technikfernen) Product Owner begreiflich zu machen, dass er bei diesem Vorgehen nicht schneller zu neuen Features kommt sondern langsamer, da alles umständlicher und fragiler wird.

Externe Störungen

Die in der Regel am schwersten zu beseitigende Art von Impediment, da diejenigen die versuchen in laufende Sprints oder am Product Owner vorbei Aufgaben an die Entwickler zu geben oder Priorisierungen zu ändern in der Regel Stakeholder und Manager mit Einfluss, Budget- und Personalverantwortung sind. Im Besten Fall lassen sie sich davon überzeugen, dass sie so nicht helfen sondern stören, im schlimmsten Fall bedarf es einer Eskalation zu ihren Vorgesetzen.

Interne Störungen

Die Art von Impediment mit der sich viele Scrum Master am schwersten tun, selbst wenn sie hier den grössten Handlungsspielraum haben. Vom narzisstischen Entwickler der Code Ownership will bis zu den Teammitgliedern die sich über Nichtigkeiten zerstritten haben - die möglichen Ursachen für zwischenmenschliche Probleme sind zahllos. Hier darf jeder Scrum Master sich als Konflikt-Moderator, Vermittler und Mediator beweisen um die beteiligten Egos wieder zusammenzubringen.

Wie oben gesagt, diese Aufzählung ist mit Sicherheit unvollständig, sie gibt aber eine Idee davon was gemeint ist wenn von der Beseitigung von Impediments die Rede ist. Sie zeigt durch ihre grosste thematische Breite auch auf was den Job des Scrum Masters so anspruchsvoll macht, denn in allen diesen Themen muss er in der Lage sein mitzureden. Dass das oft nicht der Fall ist, ist übrigens auch einer der Gründe dafür, dass sich viele so schwer damit tun zu beschreiben was Impediments sind.

Bild: Pixabay / MasterTux -

Heute gibt es mal wieder einen kleinen Erfahrungsbericht aus dem Arbeitsalltag eines Agile Coaches. Konkret geht es um ein alternatives Format zur Vermittlung von Methodenwissen. In diesem Fall von Scrum, das Vorgehen liesse sich aber auch für jedes andere Vorgehensmodell anwenden. Und um es gleich zu Beginn klarzustellen: die Idee ist zum Ausprobieren empfohlen, eine Blaupause die man einfach in grossem Ausmass auf alle Teams ausrollen sollte ist es aber nicht.

Um mit dem Hintergrund zu beginnen: vor einiger Zeit hat ein Kollege aus meiner Firma einen Kunden-Einsatz an mich übergeben zu dem auch die Begleitung eines relativ neuen Teams gehört. Das Team möchte nach Scrum arbeiten, hat aber relativ wenig Erfahrung mit diesem Framework. Normalerweise würde sich in so einem Fall eine initiale Methodenschulung anbieten, zu der es aber aus irgendeinem Fall nicht gekommen ist.¹ Stattdessen findet ein Training on the Job statt.

Um in diesem Rahmen Methodenwissen vermitteln zu können wurde im Team ein neues Format entwickelt, die so genannten "Scrum Shots". Dabei handelt es sich um kurze, fünfzehnminütige Sessions direkt nach dem Daily Scrum, in denen auf jeweils einen Askpekt des Frameworks eingegangen wird. Wegen der kurzen Zeit- und Themenmenge wurden sie nach den Shot-Gläsern benannt, deren Inhalt zwar ein geringes Volumen aber dafür eine hohe Wirksamkeit hat.

Zum Ablauf: auf einer (digitalen) Themenwand befinden sich Karten, die den 25 Abschnitten des aktuellen Scrum Guide entsprechen (Version von 2020). Am Ende jedes Scrum Shots wird vom Team per Dot-Voting darüber abgestimmt welches dieser Themen beim nächsten mal behandelt werden wird. Das wird dann von mir (bzw. vorher von meinem Vorgänger) vorbereitet und beim nächsten mal vorgestellt und gemeinsam diskutiert.

Die Art der Themenvorstellung kann sich je nach Einzelfall unterscheiden. Da wo es bisher nur oberflächliche Berührungspunkte gab macht z.B. eine grundlegende Einführung Sinn, bei Punkten die nach Schnelleinführung bereits etabliert wurden und bei denen sich bereits erste Routinen etabliert haben geht es vertieft hinein (im Fall des Daily Scrum beispielsweise in den Aspekt, dass es auch dafür gedacht ist den Fortschritt zur Erreichung des Sprint Ziels zu diskutieren).

Gegebenenfalls können darüber hinaus auch Aspekte eingefügt werden die nicht direkt aus dem Scrum-Regelwerk kommen, es aber verständlicher machen oder dessen Implikationen aufzeigen. Im Fall des Product Backlog bedeutet das etwa, dass seine wörtliche Bedeutung (der Rückstau) herausgestrichen wird, im Fall des Transparenzprinzips lässt sich diskutieren wie weit das gehen muss, zum Beispiel ob es auch auf Geschäftszahlen (inclusive der Gehälter) angewandt werden sollte.

Der Nachteil im Vergleich zu einer grösseren Schulung zu Beginn ist, dass am Anfang der Einsatz von noch nicht (oder nur verkürzt) erklärten Scrum-Elementen zu Missverständnissen führen kann, die sich schlimmstenfalls in nicht zielführenden Routinen niederschlagen können. In diesem Fall ist das zum Glück nicht passiert, bei zukünftigen Anwendungen in anderen Teams sollte man sich aber bewusst machen, dass es dazu kommen kann.

Der Vorteil ist auf der anderen Seite, dass die kontinuierliche Beschäftigung über längere Zeit dazu führt, dass die Inhalte besser ins kollektive Gedächtnis des Teams übergehen und sich dort festsetzen. Gerade vor dem Hintergrund, dass es ein häufig zu beobachtendes Phänomen ist, dass operative Alltagsthemen die Reflektion und Anwendung von methodischen Aspekten in den Hintergrund drängen, ein nicht zu verachtender Punkt.

Wie am Anfang gesagt, die Idee ist zum Ausprobieren empfohlen, eine Blaupause die man einfach in grossem Ausmass auf alle Teams ausrollen sollte ist sie aber nicht - die erwähnten Risiken zeigen auch auf warum. Sie kann auch variiert werden, z.B. durch Umwandlung in eine öffentliche, teamübergreifende Veranstaltung. Auf jeden Fall ist sie aber eine sinnvolle Option für alle Fälle in denen es aus irgendeinem Grund nicht zu einer initialen Schulung kommen kann.

Bild: Pexels / Run4FFWPU - Lizenz

Dass der Ursprung von Scrum sich irgendwo im Dunkel der Geschichte verliert hat zur Folge, dass sich Vieles nicht mehr genau nachvollziehen lässt. Da nicht absehbar war welche Popularität das Framework einmal erreichen würde wurden z.B. Entscheidungen und Entwicklungen nicht dokumentiert, weshalb bei vielen Begriffen nicht mehr genau zu sagen ist warum sie damals gewählt wurden. Zumindest bei einem ist jetzt aber Licht ins Dunkel gekommen - beim Sprint.

Verdanken tun wir das Mike Cohn, einem der ersten Scrum-Pioniere. In der ersten Folge seines Agile Mentors Podcast erzählt er, dass er bereits im Jahr 1994 mit Scrum in Berührung gekommen ist, also noch bevor es 1995 auf der OOPSLA-Konferenz erstmals der Öffentlichkeit vorgestellt wurde. Er hat es damit in seiner frühesten Form erlebt, und in der sah es noch deutlich anders aus als heute. Das betrifft auch die Sprints, deren Ursprung er wie folgt beschreibt:

In den ersten Jahren hatte Scrum (bzw. dessen Vorformen) noch starke Züge von Wasserfall. Anders als heute folgte nicht unmittelbar ein Sprint dem nächsten, stattdessen waren die Sprints lediglich die Umsetzungsphasen im Anschluss an vorgelagerte längere Planungs- und Konzeptionszeiträume. In diesen vorgelagerten Schritten wurde bereits vieles vordefiniert was danach nur noch abzuarbeiten war, und dieses finale Abarbeiten erfolgte möglichst schnell - als Endspurt, oder auf Englisch als Sprint.¹

Im Rahmen der methodischen Weiterentwicklung wurde die vorgelagerte Planung und Konzeption in den 90ern dann nach und nach als eigenständige Phase abgeschafft und in die Sprints integriert, heute findet sie sich dort in den Planning- und Refinement-Meetings wieder. Infolgedessen rückten die Sprints immer näher aneinander, bis zu der heute üblichen Regelung, in der sie nur noch durch eine logische Sekunde voneinander getrennt sind.

Man könnte argumentieren, dass man die Sprints irgendwann in dieser Zeit hätte umbenennen müssen um semantisch korrekt zu bleiben, da sie durch den Wegfall der vorgelagerten Planungsphasen ihren Endspurt-Charakter verloren haben. Andererseits liesse sich sich aber auch der Standpunkt vertreten, dass ein Sprint weiterhin der Umsetzungs-Endspurt nach den vorgelagerten Backlog Refinements ist, die jetzt während oder parallel zu den früheren Sprints stattfinden.

¹Im OOPSLA-Konferenzpapier finden sich diese Planungs- und Umsetzungsphasen noch abgeschwächt als "Pre-Game" und "Game" wieder

Grafik: Less.works - CC BY-NC-ND 2.0

Wenn es um die Skalierungsframeworks für Scrum geht sind es in den letzten Jahren vor allem drei die immer wieder genannt werden. SAFe, das vor allem in Konzernen immer populärer wird, sowie Nexus und Scrum@Scale, die den Vorteil haben, dass jeweils einer der beiden Urheber von Scrum hinter ihnen steht. Tatsächlich gibt es aber noch ein weiteres: Large Scale Scrum (abgekürzt LeSS), das 2005 entwickelt wurde und damit sogar deutlich älter ist als die drei anderen.¹

Diese Kombination aus relativ geringer Bekanntheit und relativ weit zurückliegender Entstehung hat dazu geführt, dass selbst unter den Skalierungs-erfahrenen Scrum Mastern und Agile Coaches viele sind die eine bestenfalls wolkige Vorstellung von diesem Framework haben. Je nachdem wen man fragt kann es als z.B. sehr schlank oder sehr umfangreich, als Teil des eigentlichen Scrum-Frameworks oder als separate und inhaltlich erkennbar abweichende Variante beschrieben werden.

Am schnellsten lässt sich die zuletzt genannte Unklarheit aufklären. LeSS war mal de facto ein Teil des offiziellen Scrum, hat sich aber mit dessen Versionen von 2017 und spätestens 2020 von ihm gelöst. Wesentliche neue Teile wie das Produkt-Ziel wurden nicht übernommen, gestrichene Teile wie die verpflichtenden drei Fragen im Daily wurden dagegen beibehalten. LeSS ist damit auch nach eigener Auffassung zu einer weiteren Variante geworden, die inhaltlich erkennbar eigenständig ist.

Komplizierter ist es bei der Frage wie schlank das LeSS-Framework ist. Von der Grund-Idee ist es sehr schlank, es basiert auf den Skalierungs-Aspekten die ohnehin im offiziellen Scrum-Guide stehen: wenn mehrere Teams an einem gemeinsamen Produkt arbeiten haben sie ein gemeinsames Product Backlog, einen gemeinsamen Product Owner und eine gemeinsame Definition of Done. Plannings und Reviews sind jeweils Team-übergreifend, neue Rollen und Termine werden vermieden.²

In den Büchern und auf der Website finden sich allerdings noch umfangreiche weitere Inhalte. Zugrundeliegende Prinzipien, notwendige Vorbedingungen in der Aufbau- und Ablauforganisation, Ausführungen zur Rolle des Managements, notwendige agile Praktiken der Software-Entwicklung und Anleitungen für die initiale Methodeneinführung werden hier beschrieben, in Summe kommen so mehrere hundert Seiten Text zusammen.

Die Frage ist jetzt ob diese erweiterten Inhalte als Teil von LeSS gesehen werden oder nicht. Wenn nicht ist es tatsächlich ein sehr schlankes Framework, dessen Regeln ähnlich wie die von Scrum selbst auf wenigen Seiten zusammenfassbar sind. Sind sie dagegen Teil von ihm kommt ein Gesamt-Umfang zu Stande der vermutlich zur Zeit nur noch von SAFe übertroffen wird. Entscheidend ist die eigene Interpretation, eine klare Trennung zwischen einem "LeSS-Guide" und Good Practices gibt es nicht.

Aus diesen Klärungen ergeben sich auch Implikationen für die Umsetzung. Firmen in denen für bereits nach Scrum arbeitende Teams nach einem Skalierungsframework gesucht wird sollten sich die Eigenständigkeit von LeSS bewusst machen und sich fragen wie wohl sie sich mit dem parallelen Einsatz von zwei verschiedenen Scrum-Varianten fühlen würden.³ Ist das unbedenklich kann LeSS eine interessante Option sein, da es keine zusätzlichen Rollen und Meetings erfordert.

Auch neu mit Scrum startenden Unternehmen sollte der Unterschied zum offiziellen Scrum bewusst sein, allerdings gibt es für sie ein weiteres klares Argument für LeSS: mit seinen umfangreichen Beschreibungen der notwendigen Vor- und Rahmenbedingungen geht LeSS weit über den Scrum Guide hinaus und macht die notwendigen Umstellungen in der Gesamt-Organisation besser erkennbar. Das erfordert grössere Anstrengungen, verhindert aber Optimierungen die nur lokale Effekte haben.

Für alle denen diese Vorgaben zu weit ins Detail geht und die gleichzeitig mit dem offiziellen Scrum kompatibel bleiben wollen gibt es übrigens mit Nexus eine Alternative die LeSS sehr ähnlich ist aber einen geringeren Umfang hat⁴ und auf dem aktuellen Scrum Guide aufbaut. Letztendlich gilt aber auch für beide das Urteil des Dodo: wenn sie auf den gleichen Absichten und Erkenntnissen aufbauen werden sie auch ähnliche Ergebnisse mit sich bringen.

Bild: Unsplash / Jason Goldman - Lizenz

Um mit dem Naheliegendsten anzufangen: zuerst stellt sich die Frage warum es keine zu erledigende Arbeit mehr im Sprint gibt. Es ist keineswegs immer so, dass bereits alles erledigt wurde - oft ist zwar noch Arbeit da, die aber durch fehlende Zulieferungen oder ausgefallene Systeme nicht beendet werden kann. Statt neue Arbeit nachzuziehen sollte man sich in solchen Situationen zuerst fragen ob die nötigen Zulieferungen und Reparaturen im Sprint nicht auch selbst erledigt werden können.

Selbst wenn alle Aufgaben im ursprünglichen Sprint Backlog erledigt sind müssen nicht zwangsläufig neue gesucht werden. Stattdessen kann es auch sein, dass zu der bereits erledigten Arbeit sinnvolle Ergänzungen möglich sind. Refactorings des Code können durchgeführt werden, Tests können automatisiert werden, Dokumentationen können vereinheitlicht werden, etc. etc. Das jetzt schon zu tun kann verhindern, dass später "Aufräum-Sprints" nötig werden.

Und noch etwas kann man mit der bereits fertigen Arbeit machen wenn im Sprint noch Zeit übrig ist: sie den Anwendern und Stakeholdern vorführen, deren Feedback einholen und das gegebenenfalls noch im selben Sprint nutzen um die Arbeitsergebnisse noch weiter zu verbessern. Dieser Austausch kann in Scrum auch deutlich vor dem Sprint Review stattfinden, schliesslich steht nirgendwo geschrieben, dass die Neuerungen erst da gezeigt werden dürfen.

Aber unterstellen wir, dass all das nicht möglich (oder bereits erledigt) ist und noch immer Kapazität im Sprint übrig ist. Auch dann ist die oberste Aufgabe im Product Backlog nicht automatisch die Beste. Sie sollte auch im verbleibenden Sprint abschliessbar sein. Ist das nicht der Fall besteht das Risiko, dass sich im nächsten Planning die Prioritäten ändern und dass das halbfertige Ergebnis danach so lange auf Halde liegt bis es veraltet ist und die Arbeit umsonst investiert wurde.

Ein weiterer zu berücksichtigender Fall tritt ein, wenn der Backlog-Eintrag für sich genommen noch keine nutzbare Funktionalität erzeugt.¹ Es mag zwar verlockend erscheinen durch eine frühe Umsetzung "Vorarbeit" für das nächste Sprint-Ziel zu erledigen, zum einen besteht aber auch hier das Risiko, dass es im nächsten Planning zum Umpriorisierungen kommt, zum anderen führt eine solche asynchrone Fertigstellung oft zu nicht gut abgestimmten Ergebnissen und zu höheren Integrationsaufwänden.

Um es auch von der positiven Seite zu betrachten - was kann man denn guten Gewissens in einen Sprint nachziehen? Idealerweise Arbeitspakete deren Umsetzung bereits für sich genommen einen Mehrwert erzeugt und die in der noch verbleibenden Zeit des Sprints vollständig umsetzbar sind. Selbst wenn sie nicht die höchste Priorität im Backlög haben sollten stiften sie einen Mehrwert, gleichzeitig können die in den letzten Absätzen genannten Risiken vermieden werden.

Falls sie alle in der verbleibenden Zeit umsetzbar sind können auch mehrere zusammengehörende Backlog-Einträge in den Sprint gezogen werden, die sich dann durch ein "Zusatz-Sprintziel"² verbinden lassen. Gegebenenfalls ist es zu diesem Zweck auch möglich aus einem für die verbleibende Sprintdauer zu grossen Ziel einen Spike, ein Proof of Concept oder ein MVP herauszulösen, das auch allein für sich genommen von Wert ist.

Was ich auch schon erlebt habe ist, dass sich Teams die ihr Sprintziel vorzeitig erreicht haben aus dem Backlog eine "Carte Blanche" ziehen konnten, mit der sie an allem arbeiten konnten wozu sie sonst nicht gekommen sind, vom Abbau technischer Schulden über die Verbesserung der eigenen Entwicklungstools bis hin zum Erlernen neuer Programmiersprachen. Für viele war das ein zusätzlicher Anreiz um ihre Arbeit möglichst schnell und gut zu erledigen.³

Und ganz zuletzt - vielleicht muss man auch gar keine Arbeit nachziehen und kann stattdessen Überstunden abbauen. Auch das passiert in manchen Teams viel zu selten.

Als Fan des Extreme Programming (XP) freut es mich jedesmal wieder wenn dieses Framework öffentlichkeitswirksam in den Mittelpunkt gerückt wird, gerade auch deshalb weil das mittlerweile nur noch relativ selten passiert. Den Vortrag "Putting the XP in Scrum" von Roy Osherove kann ich daher nur empfehlen.

Interessant ist bei seinen Ausführungen die Einordnung. Für ihn besteht agile Softwareentwicklung aus zwei Elementen: dem aus Scrum abgeleiteten iterativ-incrementellen Prozess und der aus DevOps übernommenen Nutzung automatisierter Build-Pipelines. Da Extreme Programming sowohl einen mit Scrum kompatiblen Prozess-Anteil als auch mit DevOps verwandte Entwicklungspraktiken hat ist es für Osherove der "missing Link", der die beiden anderen Ansätze miteinander verbindet.

Bild: Pexels / Karolina Grabowska - Lizenz

Nach über 10 Jahren als Scrum Master, Agile Coach und in anderen "agilen Rollen" ist so einiges an Erfahrungen zusammengekommen die ich mit der Zeit gemacht habe, sowohl im Guten als auch im Schlechten. Basierend darauf gibt es eine Frage, die mir immer wieder gestellt wird: ob es eine erkennbar schlimmste Umsetzung von Scrum unter denen gegeben hat, die ich erlebt habe. Und tatsächlich gibt es sie, die eine, die so übel war, dass sie wirklich aus allem heraussticht. Haltet Euch fest.

Der Kunde war ein Mittelständler aus Süddeutschland. Scrum war dort ein Jahr zuvor von einer grossen, mit A beginnenden Unternehmensberatung eingeführt und als revolutionäre Prozess-Optimierung angekündigt worden. In der Wahrnehmung des oberen Managements liessen die sichtbaren Verbesserungen aber auf sich warten, weshalb ein externer Experte (ich) überprüfen sollte, ob das Vorgehen tatsächlich so umgesetzt wurde wie gedacht. Ich begann entlang der Wertschöpfungskette.

Die erste Überraschung erwartete mich gleich zu Beginn, denn am Anfang der Wertschöpfungskette befand sich eine Fachabteilung, die ein Lastenheft verfasste, also eines jener Telefonbuch-dicken Dokumente, die alles an Wünschen enthalten, was der beauftragenden Einheit sinnvoll erscheint. Nichts davon war durch Marktforschung oder Kundenfeedback validiert, nichts davon war durch eine Machbarkeitsanalyse oder eine Aufwandsschätzung gegangen.

Dieses Lastenheft ging im nächsten Schritt an das Anforderungsmanagement, das den Auftrag hatte, es in User Stories herunterzubrechen. Die Unternehmensberatung mit A hatte dafür eine Anleitung hinterlassen, der zufolge alle User Stories mit "als User möchte ich" beginnen mussten (der Zwecksatz fehlte dagegegen) und klein genug sein mussten, um von einem einzigen Entwickler in einem Tag umgesetzt werden zu können.

Um dieses Anforderungsmanagement zu Höchstleitungen anzuspornen, wurde seine Leistung an der Menge der geschriebenen User Stories gemessen. Um möglichst viele erzeugen zu können wurden diese folgerichtig noch kleiner als gefordert, zwei an die ich mich erinnern kann waren "Als User möchte ich, dass sich das Dropdown-Menue öffnet wenn man es anklickt" und "Als User möchte ich, dass das geöffnete Dropdown-Menue anklickbare Items enthält". Insgesamt waren es tausende.

Die so verfassten User Stories gingen als nächstes in das so genannte "Planning I", in dem der IT-Chef und die Architekten sie auf einen Zeitstrahl verteilten, der bis weit in das nächste Jahr hineinreichte. Aufgrund der schieren Masse (nochmal: tausende) wurden dabei nicht alle genau angeschaut, das Hauptkriterium war, dass ungefähr gleich viele in jedem Monat landeten. "Langfristig mittelt sich das", wurde als Begründung für dieses Vorgehen genannt.

Kurz vor Beginn eines Monats (der hier einem Sprint entsprach) folgte jeweils das "Planning II". Die Architekten und der in diesem Moment erstmals beteiligte Product Owner schätzten für jede der für diesen Monat eingeplanten User Stories den Aufwand und entschieden, welchem Entwickler sie zugewiesen werden würden. Zusätzlich dazu verfassten sie neue User Stories für dringende Bugs ("Als PO möchte ich, dass Bugticket XY im nächsten Sprint gefixt wird") und wiesen auch die zu.

Am ersten Arbeitstag des Monats, bzw. Sprints folgte schliesslich das "Planning III". In dem wurde nacheinander jeder Entwickler in einen Raum gebeten, in dem er von dem PO, den Architekten und seinem Abteilungsleiter (diese Rolle war in Personalunion auch Scrum Master) erwartet wurde. Dieses Kommittee erklärte dem einzeln vor ihm stehenden Entwickler, welche Arbeit für ihn eingeplant war, erlaubte es ihm, Verständnisfragen zu stellen und forderte ihn auf die Lieferung zuzusagen.

Dass diese Zusage auch eingehalten wurde, wurde im Sprint in den Daily Scrums sichergestellt. Die Scrum Teams (jeweils 15 bis 25 Entwickler) versammelten sich in einem Raum, der Abteilungsleiter/Scrum Master filterte das digitale Sprint Backlog nach Bearbeitern und forderte nacheinander jeden auf vorzutreten und einen Statusbericht abzugeben. Da dieser Termin länger als eine Stunde war, konnte jeder direkt nach seinem Bericht zurück an die Arbeit, um so produktiver zu sein.

Erfahrungsgemäss zeigte sich in den meisten Sprints etwa in ihrer Mitte, dass sie zu optimistisch geplant waren. Um das auszugleichen, forderten die Abteilungsleiter/Scrum Master die Entwickler zu Überstunden auf oder verschoben User Stories zu anderen, die noch nicht im Rückstand waren. Neu entdeckte Bugs wurden in das "Bug Backlog" verschoben, aus dem alle die nicht dringend waren in einem der halbjährlich stattfinden "Bugfixing-Sprints" eingeplant wurden.

Im am Ende des Sprints stattfindenden Review Meeting überprüften die Architekten, die Product Owner und die Abteilungsleiter/Scrum Master ob alle User Stories wie geplant fertiggestellt worden waren, falls das nicht der Fall war konnten einzelne Entwickler in dem Raum geholt werden um ihren Rückstand zu erklären. Die Ergebnisse des Reviews wurden im Anschluss schriftlich dem Steuerungskommittee mitgeteilt, in dem u.a. der IT-Chef und die beauftragende Fachabteilung sassen.

Retrospektiven gab es keine. Sie hatten wohl früher stattgefunden, waren aber wegen Ineffektivität wieder abgeschafft worden.

Wie man sich denken kann, konnte ich bereits nach wenigen Tagen mit einer umfangreichen Liste an identifizierten Missständen und konkreten Handlungsempfehlungen aufwarten. Ich hatte schon geahnt, dass sie keine Begeisterung auslösen würden, und genau so kam es. Ich sollte doch stattdessen bitte "pragmatische Lösungen" erarbeiten, die ohne grundlegendes Infragestellen der bestehenden Prozesse umsetzbar wären. Das wollte ich nicht, und als Folge dessen beendete die Firma unsere Zusammenarbeit.

Und das ist sie, die Geschichte der schlimmsten Umsetzung von Scrum, die ich jemals erlebt habe. Ich habe später noch mitbekommen, dass in den folgenden Monaten über die Hälfte der Angestellten aus der IT gekündigt hat und dass weitere Unternehmensberatungen beauftragt wurden. Ob es eine Moral gibt, die man daraus ziehen kann weiss ich nicht, vielleicht ist es diese hier: egal wie vermurkst Dir Deine agile Transformation erscheinen mag - irgendwo ist es schlimmer.

Bild: Akson / Unsplash - Lizenz

Zu den immer wiederkehrenden Diskussionen bei nahezu jeder Scrum-Einführung gehört die um die Frage ob der Scrum Master eine Vollzeitstelle ist ob diese Rolle auch in Teilzeit ausgefüllt werden kann. Während die meisten Agile Coaches und auch die meisten Scrum Master selbst das verneinen würden ist in den meisten Organisationen die sich an agilem Arbeiten versuchen die Versuchung gross es doch zu probieren, schliesslich liesse sich dadurch einiges an Budget sparen.

Das Problem bei derartigen Versuchen ist, dass damit mittlerweile ein gewisses Stigma verbunden ist. Wer auch immer seinen Scrum Mastern die Vollzeitstelle verweigert gerät in den Ruf es mit der Agilität nicht ernst zu meinen oder sie (bewusst oder unbewusst) kaputtzusparen. Um diesem Stigma zu entkommen werden mittlerweile alle Fälle in denen ein bekannter Agilist sich für den Teilzeit-Scrum Master ausspricht von interessierter Seite demonstrativ hervorgehoben. So auch dieser hier:¹

Oh ha. Einer der beiden Väter von Scrum sieht den Scrum Master als halbe Stelle? Seit einiger Zeit wird dieses Zitat immer wieder in der agilen Filterblase und darüber hinaus weitergereicht und geteilt, scheint es doch der dominierenden Meinung mit der grösstmöglichen Methoden-Autorität zu wiedersprechen die dieses Framework zu bieten hat. Wie immer empfiehlt sich aber auch hier ein näherer Blick. Was steckt wirklich in diesem Zitat?

Zunächst lohnt es sich auf ein kleines Wort aufmerksam zu machen. Laut Sutherland sind die meisten guten Scrum Master ("great Scrum Masters") die er kennt in Teilzeit unterwegs. Darin steckt mehr als es zunächst scheint - ein Scrum Master ist nicht als Person gut oder schlecht, er ist es im Kontext seines Teams, dessen Teil er schliesslich ist (siehe hier). Und da gute Teams wenig betreuungsintensiv sind, sind ihre Scrum Master entsprechend weniger gefordert.

Umgekehrt erfordern unerfahrene Teams in der Regel einen eher hohen Betreuungsaufwand des Scrum Masters, bis zu dem Punkt, dass er bestimmte Handlungen nicht zulässt (z.B. das Ausfallen Lassen der Retrospektive um "mehr Zeit für das Arbeiten zu haben"). Damit greift er in die Selbstorganisation der Entwickler ein, und macht dadurch in puristischer Scrum-Interpretation keinen guten Job - was aber auch bedeutet, dass ihn diese (noch) nicht gute Rollenausübung meistens in Vollzeit beansprucht.

Ebenfalls zu beachten ist ein weiterer Aspekt: wie stark auf das Team fixiert ist die Rolle? Im klassischen Scrum findet ein Grossteil der Scrum Master-Tätigkeiten in der umgebenden Organisation statt (was meistens Vollzeit erfordert), nur wenn ihm diese Zuständigkeit genommen und auf andere Rollen übertragen wird bleibt ihm mehr Zeit. Und jetzt kommt's: zu diesen Rollen gehört nicht nur der SAFe-Release Train Engineer sondern auch der "Scrum of Scrums-Master" in Scrum@Scale, dem Skalierungsframework von - Jeff Sutherland. Was für ein Zufall.

Zusammengefasst bedeutet das, dass die Frage nach der Teilzeiteignung der Scrum Master-Rolle nicht klar zu beantworten ist, es gibt Gründe dafür und dagegen, und selbst bei prominenten Fürsprechern für eine der beiden Varianten lohnt sich ein Blick auf die damit verbundenen Motivationen. Vielleicht ist das aber auch das passende Fazit dieser Erwägungen - im Zweifel ist es immer eine gute Idee selbst nachzudenken und nach der individuell passenden Lösung zu suchen. Gerne mit Inspect & Adapt.

Und für alle denen das zu unkonkret ist gibt es eine einfache Faustregel: hätte der Scrum Master auch in Teilzeit ausreichend Ruhe und Zeit um regelmässig aus dem Hamsterrad herauszusteigen und sich Gedanken wie diese hier zu machen? Wenn ja kann er auch eine zweite Aufgabe im Team übernehmen, wenn nicht, dann nicht.