Die Grundlagen-Dokumente von Scrum (Update 2021)
 |
| Bild: Pexels / Suzy Hazelwood - Lizenz |
Manchmal gibt es diese Momente: kurz nachdem ich im Sommer 2020 die Übersicht über die Grundlagen-Dokumente von Scrum erstellt hatte wurde eine neue Version des Scrum Guide angekündigt und nachdem dieser im November veröffentlicht wurde folgten im Januar die neuen Versionen von Nexus und Scrum@Scale. Zeit für ein Update dieser Zusammenstellung. Dabei bin ich auch auf einige Feedbacks eingegangen, auf andere nicht. Mehr dazu ganz unten. Aber jetzt erstmal - auf in die Geschichte. Durch die folgenden Dokumente hat sich Scrum in seine heutige Form entwickelt:
Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.
Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Leiter eines Product Management-Teams), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.
Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.
Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Entstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.
In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch die Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).
Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.
Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.
Selbst in der langfristigen Betrachtung ein kurioses Konferenz-Paper, gleichzeitig aber auch ein wichtiges. Der Bericht von Jeff Sutherland und seiner Frau Arline über den Einsatz von Scrum bei der Organisation von verschiedenen Kirchengemeinden ist die erste Primärquelle in der ein Einsatz des Frameworks in einem komplett IT-freien Kontext beschrieben wird. Damit nimmt es die offizielle Herauslösung von Scrum aus der Software-Erstellung um einige Jahre vorweg und bereitet den Weg für Varianten wie Hardware-Scrum, EduScrum, etc.
Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Pig" (Teammitglied) und "Chicken" (Stakeholder) tauchen ein letztes mal auf. Der Scrum Master wird als helfender und coachender "Servant Leader" beschrieben, was erst 10 Jahre später zu "True Leader" geändert wurde. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.
Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch offiziell auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.
Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.
Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.
Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die zusätzliche Mitgliedschaft von Experten und ausgewählten Teammitgliedern in einem übergreifenden Integration-Scrum Team, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).
Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.
Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.
Das übergreifende Integration Team ist selbst kein Scrum Team mehr, um konkurrierende Mitgliedschaften zu vermeiden, es funktioniert jetzt eher wie ein um externe Experten erweitertes Scrum of Scrums. Darüber hinaus gibt es redaktionelle Änderungen, unter anderem um klarer herauszustellen, dass der Nexus Guide an den Scrum Guide angelehnt ist und nicht zu ihm in Widerspruch stehen kann.
Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass das eigentliche Scrum Framework nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese aber aus Delegierten der jeweils nächstunteren Ebene bestehen, die sich auch als Scrum Teams organisieren. Dabei gibt es zwei parallele Hierarchien: die Scrum of Scrums, Scrum of Scrum of Scrums, etc. für die Scrum Master und die gleichartig gestaffelten Meta-Scrums für die Product Owner. Auf diesen höheren Ebenen entstehen auch die neuen Rollen des "Scrum of Scrums Master" und des "Chief Product Owner" (samt deren Steigerungen).
Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.
Je nach Betrachtung eine der umfangreichsten Änderungen überhaupt oder lediglich eine grundlegende redaktionelle Überarbeitung. Die offensichtlichste Neuerung ist die Einführung des Produktziels, an dem sich das Product Backlog ähnlich ausrichtet wie das Sprint Backlog am Sprint Ziel. Das Planning besteht jetzt aus drei Teilen, die den Fragen Warum, Was und Wie entsprechen. Die drei Fragen im Daily Scrum sind völlig verschwunden, ebenfalls die erst in der letzten Version eingeführte Aufnahme von Prozessverbesserungen in das Sprint Backlog. Dass Teams mit gemeinsamem Product Backlog auch einen gemeinsamen Product Owner haben müssen ist jetzt auch explizit beschrieben. Um den Eindruck konkurrierender Mitgliedschaften zu vermeiden gibt es innerhalb des Scrum Teams kein Entwicklungsteam mehr sondern nur noch Entwickler. Durch klarere Formulierung und Strukturierung ist diese Version mehrere Seiten kürzer als die letzte, dazu kommen angepasste Begrifflichkeiten, etwa True Leader statt Servant Leader.
Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt.
Anpassung an die letzten Änderungen des Scrum Guide, z.B. durch Aufnahme des Produktziels. Weitere nennenswerte inhaltliche Veränderungen finden nicht statt. Darüber hinaus gibt es redaktionelle Änderungen und angepasste Begrifflichkeiten, beides mit dem Ziel, dass es genau wie bei der letzten Version des Scrum Guide zu einem geringeren Umfang und klareren Formulierungen kommen soll.
---
Honorable Mentions
Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde, den EduScrum Guide von Willy Wijnands und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).
Zum Feedback zu dieser Seite
Einige Worte zu dem Feedback das ich angenommen oder nicht angenommen habe: neu in der Liste ist Scrum in Church, ausserdem auch die Übersicht über die einzelnen Versionen von Nexus und Scrum@Scale, statt wie bisher nur auf die jeweils neueste Version zu verlinken. Da die jeweiligen Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide inhaltlich zusammenhängen macht das Sinn.
Nicht aufgenommen habe ich dagegen Large Scale Scrum (LeSS), Scrum 3.0 und die Scrum-Varianten aus SAFe und Disciplined Agile (DA). Bei LeSS und Scrum 3.0 weil sie nichts Wesentliches hinzufügen was es nicht bereits von Schwaber und Sutherland gibt, bei SAFe und DA weil sie Scrum so stark beschneiden, dass das Ergebnis mit dem Original nur noch eingeschränkt zu tun hat.
Weiteres Feedback ist jederzeit willkommen, spätestens zusammen mit den nächsten Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide gibt es dann auch von dieser Seite eine neue Version in die es gegebenenfalls eingearbeitet wird.
