✁
digitalien.org — Stefan Knecht
Scrum in einfach
Der Scrum Guide wird hin und wieder um Kleinigkeiten angepasst. Dieser Beitrag bietet eine Beschreibung in einfachen Bildern und so wenig Text wie nötig.
Ein ‘leichtgewichtiges Rahmenwerk’ ist Scrum: leicht zu verstehen, nicht ganz so leicht umzusetzen. Diese Darstellung ist, was ich gerne gehabt hätte … baue ich das eben selbst.
Der offizielle Scrum Guide ist die Basis, Illustrationen sind generisch. Verwenden Sie diese gerne mit dem Hinweis auf die CC-Lizenz im Footer.
Der Scrum Flow
Das ganze Große zuerst — daran werden wir uns Stück für Stück anschleichen.
Blaue Bezeichnungen sind Artefakte, also Dokumente im weiteren Sinne. Rote Bezeichnungen sind wiederkehrende Ereignisse oder Rituale. Graue Begriffe sind Praktiken oder Elemente, die so nicht im Scrum Guide stehen, sich in der Praxis doch manchmal als nützlich erwiesen.
(Vergessen Sie das ganze Bild für den Moment gleich wieder.)
Sprint als regelmäßiger Ablauf
Scrum wird verständlicher, wenn es von Grund aufgebaut wird. Grundlage ist die Regelmässigkeit des Sprint (Zyklus, Kadenz) als zeitliche Sequenz, in der sich Abläufe wiederholen. Wie lange ein Sprint ist, bildet sich von alleine heraus, zwischen zwei bis vier Wochen ist häufig.
Diese Gleichmäßigkeit soll Lastspitzen verhindern und ermöglicht, stetig nützliche Ergebnisse zu schaffen.
Inkremente als nützliche Teillieferungen
Ergebnis jedes Sprint ist eine nutzbare Teillieferung eines zunehmend besseren Produktes. Jedes Inkrement (die kleinen blauen Dinger im Geschenkkarton) aus einem Sprint steigert den Nutzen. Das Produkt ist fertig, wenn dieses Ziel erreicht ist. Scrum hat seinen Zweck erfüllt.
Review: Nutzen schnell prüfen
Damit der Nutzen schnell geprüft werden kann, wird jedes Inkrement — sobald es vorzeigbar ist — in einem Review dem Auftraggeber vorgestellt. Sie kann sagen, ob es genau die Bedürfnisse erfüllt oder noch Nachgearbeitet werden sollte. So vergeht möglichst wenig Zeit und es wird produziert, was wirklich hilft. Vielleicht ändern sich ja zwischenzeitlich Randbedingungen oder Bedürfnisse. So wird genau produziert, was jetzt benötigt wird. Es vergeht weniger Zeit und idealerweise wird nichts auf Vorrat hergestellt.
Wenn es Auftraggeber gibt, dann auch Auftragnehmer. Im Scrum Team mit drei Rollen sind die Entwickler Auftragnehmer des Product Owner:
Entwickler bauen das Produkt. Genau ein Product Owner weiss so gut als möglich, wie das Produkt sein soll. Ein Scrum Master hilft mit, dass alle Beteiligten miteinander gut arbeiten und macht das so lange und intensiv, bis das Scrum Team dies selbst tun kann.
Planung: so viel es braucht
Damit in einem Sprint auch das nächstnützliche Inkrement entstehen kann, wird zu Beginn so viel geplant, wie für diesen Zyklus hinreichend. Also gerade so viel Vorlauf, wie es braucht um das Inkrement herzustellen.
Ein kurz formuliertes Sprint Goal beschreibt, was inhaltlich im nächsten Zyklus herauskommen soll. Das hilft, sich gerade so viel vorzunehmen, dass alle Beteiligten es auch gut leisten können. Wie das dann gemacht werden könnte, überlegt sich das Entwicklungsteam nachdem das Ziel vereinbart ist. Das Sprint Backlog hält alles für den laufenden Sprint zusammen.
Der Backlog als transparenter Speicher
Das Sprint Backlog speist sich aus dem Product Backlog. Dort steht in zunehmend besserer Detailierung, was getan werden muss, damit mit dem letzten ausgelieferten Inkrement genau jenes Produkt realisiert ist, das der Product Owner braucht.
Dieses Product Backlog ist also ein gepflegter und nach Nützlichkeit geordneter Speicher von allem, was getan werden könnte um das Produkt komplett fertigzustellen. Es ‘gehört’ dem Product Owner: sie kann darin rangieren und priorisieren. Alle anderen sehen ständig Änderungen, können mitarbeiten und Hinweise geben. Nicht alles, was getan werden könnte, muss auch getan werden: diese Teilmenge wird ständig in Refinements lateral im Scrum Team verhandelt.
Retrospektiven: Lernen im Tun
Bei diesem ständigen Detaillieren und Verhandeln kann immer auch etwas gelernt werden: wie es besser, leichter gehen könnte, was Mitarbeitende brauchen um gut arbeiten zu können oder was nicht so gut funktioniert hat. Damit dieses Lernen realisiert wird, hat der Scrum Flow als Retro(spektive) ein rituelles Ereignis zum Ende jedes Sprint. Innerhalb des Scrum Team wird die aktuelle Kadenz betrachtet und gefragt: Was lief prima, was können wir besser machen?
Das war nun der große Kreis, ein ganzer Sprint. Vom Sprint Planning zum Review eines Inkrementes zum ritualisierten Lernen aus der Rückschau.
Tag für Tag geschehen im Sprint-Zyklus ständig weitere Dinge:
Tägliche Synchronisierung
An jedem Tag im Sprint gibt es ein Daily Scrum. Mindestens das Entwicklungsteam spricht miteinander, aktualisiert und synchronisiert sich: »Was habe ich gemacht, was werde ich machen, wo brauche ich Unterstützung?« sind typische drei Fragen, die in einer Viertelstunde reihum gehen. Danach weiß jede:r, wie es steht und kann nützliche Arbeit tun. Ein Scrum Board macht alles transparent.
Bereit und fertig definieren
Zwei weitere Praktiken helfen manchmal und sind im Scrum Guide lose beschrieben. Eine DoR beschreibt als ‘definition of ready’, wie tief detailliert etwas sein soll, damit es in einem Sprint in das Sprint Backlog gelangen kann. Eine DoD als ‘definition of done’ beschreibt Attribute, die vorhanden sein müssen, damit etwas tatsächlich fertigfertig ist, also nichts weiter daran gearbeitet werden muss.
Manche Teams schätzen den ‘Wert’ jedes item im Backlog, anderer kommen ohne aus. Der Scrum Guide sagt dazu nichts.
Die Taktung, das Miteinander-Reden, Zurückblicken und Lernen steckt also tief in Scrum wie in den kleinen Merkbildern der OODA- und PCDA-Zyklen. Sie meinen das Gleiche.
So funktioniert Scrum: In kleinen Stücken arbeiten und viel miteinander reden. — Es ist ganz einfach.