Scrum ist «extrem schwer zu meistern»

Unvoreingenommen und ahnungslos liess ich mir am Fachreferat «Komplexität braucht Empirismus, darum Scrum» von Ralph Jocham Scrum näherbringen. Das Konzept hinter dem Rahmenwerk Scrum ist ziemlich simpel: Es gibt Scrum Teams und mit ihnen verbundene Rollen (Product Owner, Scrum Master und Entwicklungsteam), Ereignisse, Artefakte und bewährte agile Praktiken. Im Gegensatz zum Wasserfallmodell, bei dem phasenweise und aktivitätsorientiert vorgegangen wird, besteht ein Scrum-Projekt aus einzelnen sogenannten Sprints, die sich nicht auf eine Aktivität fokussieren, sondern Funktionalität liefern. Sämtliche Phasen eines definierten Projektablaufs werden bei Scrum entsprechend in sehr viel kürzerer Zeit (maximal 30 Tage) in einem Sprint zusammengefasst und für viele kleinere, aber maximal wertschöpfende Funktionalitäten bzw. Artefakte durchgeführt. Dies bedeutet, dass während der Projektlaufzeit laufend Funktionalitäten entwickelt werden, die idealerweise nach jedem Sprint einsatzfähig sind; es kann also je nach Bedarf viele kleine Releases geben. Beim Phasenmodell hat man im Gegensatz nur einen grossen Release am Ende des Projekts.

Jeden Monat einen Sprint

In untenstehender Abbildung ist ein einzelner Sprint aufgezeichnet, der sich während der Projektlaufzeit wiederholt. Am Anfang steht der Product Backlog mit dem Product Owner als Verantwortlichem. Es folgen drei Entwicklerteams, die alle für sich ein Produktinkrement liefern. Was schliesslich interessiert, ist aber das kombinierte Produkt, das sich aus den drei kleinen Inkrementen ergibt. Es folgt das Review und die Retrospektive, bevor man in einen neuen Sprint geht.

Scrum basiert auf Empirismus

Scrum geht davon aus, dass wir im Projekt Wissen durch Erfahrungen gewinnen und auf der Basis von Fakten entscheiden. Der Ansatz dahinter ist inkrementell und iterativ, soll heissen: Im Projekt wird schrittweise vorgegangen und die einzelnen Schritte werden ständig wiederholt und fortlaufend verbessert. Die Kernpunkte von Scrum sind Transparenz, Überprüfung und Anpassung. Zu Anfang definiert man ein gemeinsames Verständnis. Alle Beteiligten müssen dieselbe Sprache sprechen und vom selben Endergebnis ausgehen (siehe Definition of Done). Entstehende Artefakte und Fortschritte werden permanent überprüft. Wenn festgestellt wird, dass ein Vorgehen oder Arbeitsgegenstand nicht akzeptabel ist, nimmt man umgehend Anpassungen vor.

Der Product Backlog

Das Herzstück eines Scrum-Projekts ist der Product Backlog. Dies ist eine Liste mit allem, was für das gewünschte Produkt nach dem momentanen Wissen benötigt wird. Der Product Owner ist für die Inhalte, die Priorisierung der in der Liste stehenden Funktionalitäten und die Bereitstellung der Liste verantwortlich. Es liegt in der Natur des Product Backlogs, dass er sich ständig ändern kann. Funktionalitäten können in der Reihenfolge ändern, können hinzukommen oder gestrichen werden. Auch wenn mehrere Entwicklerteams am selben Scrum-Projekt für ein Produkt arbeiten, wird ein einziger Product Backlog verwendet.

Scrum gibt keine Antwort

Von Scrum darf man keine vordefinierten Handlungsweisen und Antworten erwarten. Es stellt ganz einfach einen Rahmen dar, nach dem wir vorgehen können. Aber: Bereits in der Einleitung des Scrum Guides sagen die beiden Autoren Ken Schwaber und Jeff Sutherland: «Scrum ist (…) extrem schwer zu meistern.» Scrum übernimmt für uns nicht das Denken, unterstützt uns aber dabei, indem alles im Projekt transparent gemacht wird.

Bilderquelle: Referat «Komplexität braucht Empirismus, darum Scrum» (6.11.12) von Ralph Jocham. Hier gehts zu den Slides