On Lean and Agility

Bis zur Überarbeitung des Scrum Guide im Jahr 2020 enthielt er in Bezug auf die Definition of Done (DoD), sein zentrales Quality Gate, durch das alle neu erstellten Funktionalitäten passieren müssen, eine Formulierung, die zumindest aus meiner Sicht hochgradig kontrovers war. Sinngemäss stand in ihr, dass die Qualität des erzeugten Produkt oder Service sich verbessern liesse, indem der Umfang der DoD vergrössert würde. Oder im englischen Original:

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

Scrum Guide, 2017 Version

Nun ist dieser Passus wie gesagt seit dem Jahr 2020 Geschichte, er ist aber in vielen Teams und Organisationen noch immer im expliziten oder impliziten Verständnis von Scrum hängengeblieben. Daher lohnt sich eine nähere Betrachtung - warum kann die Idee einer "expandierenden Definition of Done" problematisch sein, und unter welchen Umständen ist es möglich, diese negativen Aspekte zu vermeiden oder sogar ins Vorteilhafte zu drehen?

Um mit dem problematischen Teil zu beginnen: eine DoD, die versucht, umfassend alle Eventualitäten zu regeln, wird zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen sind. Das ist eine Falle, in die viele Teams tappen. Vor allem in Wikis oder shared Docs mit ihrem unbegrenzten Platz kann es zu einem wuchenden Wachstum von manchmal geradezu absurdem Ausmass kommen.¹

Derartig aufgeblähte Dokumente sorgen dafür, dass die von ihnen betroffenen Teams und Projekte in einer Zwickmühle sitzen. Entweder stellen sie sicher, dass alles was dort steht befolgt und eingehalten wird, verbunden mit einem erheblichen Verwaltungs- und Dokumentationsaufwand. Oder sie riskieren, dass sie einzelne Elemente vergessen und übersehen und damit nicht einhalten (oder die Unübersichtlichkeit führt versehentlich dazu, dass einzelne Teile sich gegenseitig widersprechen).

Jetzt zum positiven Fall, bzw. zu der Frage, wie dieser aussehen kann. Die (vor allem für IT-Produkte naheliegende) Antwort - automatisiert. Genauer gesagt, die Einhaltungs-Überprüfung der DoD findet automatisiert statt. Vorgaben wie Testabdeckung, Lastfähigkeit, maximale Verschachtelungstiefe des Code, das Nichtvorhandensein von auskommentierten oder ausgetoggleten Features oder sogar korrekte Rechtschreibung lassen sich durch automatisierte Tests schnell validieren - auch in grossem Umfang.

Für Teams und Organisationen die so vorgehen wollen, ergibt sich dadurch die folgende Richtlinie: eine Definition of Done wird nur dann durch einen zunehmenden Umfang besser, wenn die enthaltenen Vorgaben zum Grossteil automatisiert validierbar sind.² Die nicht automatisiert überprüfbaren Teile können zwar ihre Berechtigung haben, um Unübersichtlichkeit und Bürokratie zu vermeiden, sollten sie aber regelmässig überprüft und ggf. verschlankt werden.

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 nur 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.