SCRUM und Bergwandern – haben diese beiden eigentlich grundverschiedenen Themen doch etwas gemeinsam? Diesem Theorem wollte ich, zwar nicht hauptsächlich, bei einer 8-tägigen Alpenüberquerung auf den Grund gehen.
Die Tour: der Klassiker – E5 von Oberstdorf nach Meran.
SCRUM in a nutshell
In SCRUM gibt es 3 Rollen
- den Product Owner – stellt fachliche Anforderungen und priorisiert diese
- den SCRUM Master – überwacht den Prozess und beseitigt Hindernisse
- und das Team – entwickelt das Produkt
Weiterhin gibt es den Product Backlog. In dieser Liste werden alle Anforderungen (Requirements) gepflegt, aktualisiert und priorisiert.
Ein Sprint ist ein Zeitabschnitt von maximal 4 Wochen, in dem ein Inkrement einer Produktfunktionalität implementiert wird. Beginn ist das Sprint Planning und Ende der Sprint Review mit Retrospektive. Für einen Sprint werden die Anforderungen aus dem Product Backlog in konkretere Task herunter gebrochen und im sogenannten Sprint Backlog mit zuständigem Bearbeiter und täglich aktualisiertem Restaufwand festgehalten. Das Ziel eines jeden Sprints ist ein Potentially Shippable Product.
Jeden Tag trifft sich das Team in einem auf 15 Minuten begrenzten Meeting, dem Daily SCRUM. Dadurch weiß man jederzeit, woran der andere zuletzt gearbeitet hat, was er als nächstes vor hat und welche Probleme es eventuell gibt.
SCRUM ist also eine agile und inkrementellen Methodik mit definierten Zeitabschnitten (Time-Boxes) und der Annahme, dass ein funktionierendes Produkt wichtiger ist als eine vorab geschriebene Feinspezifikation. Ebenfalls besonders betont ist die Verantwortlichkeit, ständige Kommunikation / Abstimmung innerhalb und mit dem Product Owner und die Autarkie des Teams.
Quelle: Wikipedia.org
Welche Gemeinsamkeiten und Unterschiede haben nun SCRUM und eine Alpenüberquerung?
Wir können den Product Owner mit den Berg gleichsetzen, den SCRUM Master mit dem Bergführer und das Team mit der Wandergruppe. Der Product Backlog sind die einzelnen Etappen, der Sprint ist eine Tagesetappe, der Sprint Backlog die jeweiligen Zwischenziele und das Shippable Product das Erreichen der Übernachtungsmöglichkeit.
So könnten nun ein Berg-Sprint aussehen:
Natürlich sind die Einheiten deutlich kleiner, aber dennoch vergleichbar. Morgens beim Frühstück wird im Sprint Planing die Tagesetappe geplant. Am Abend zuvor wurde bereits das Sprint Review durchgeführt. Das Daily Meeting findet unterwegs bei den Zwischenetappen statt.
Wichtiger als die rein formellen Ähnlichkeiten sind aber die inhaltlichen Gemeinsamkeiten. Es herrscht eine ständige Abstimmung im Team. Meistens wird am Berg hintereinander gegangen und man muss sich auf seinen Vordermann verlassen. Der Bergführer geht voran, weist auf Risiken hin und motiviert das Team, wenn es (oder ein Einzelner) an seine Grenzen gekommen ist. Weiterhin sorgt er dafür, dass die durchaus vorhandenen Risiken minimiert werden.
„Ein Sprint wird niemals verlängert“
Es gibt allerdings auch Unterschiede. Beispielsweise die Aussage „Ein Sprint wird niemals verlängert – er ist zu Ende, wenn die Zeit um ist“ kann nicht auf die Bergwanderung übertragen werden. Denn mitten am Berg kann man nicht einfach stehen bleiben, ein Sprint Review ansetzen und nicht fertige Tasks auf den nächsten Sprint schieben. Und schon gar nicht wenn der Wind pfeift und die Berghütte noch eine Stunde entfernt ist. Das wiederum ist eine Gemeinsamkeit zum realen Projektleben. Auch hier kann es manchmal Gründe geben einen Sprint zu verlängern, damit Tasks noch fertiggestellt werden können. Hier sollte man pragmatisch an die Sache rangehen und nicht zu sehr auf der Methodik beharren, um für den Kunden das bestmögliche Ergebnis zu liefern.
Die für mich aber entscheidende Analogie und gleichzeitig wichtigster Erfolgsfaktor für das Gelingen eines jeden (agilen) Projektes ist, dass sich jeder im Team mit seinen Kenntnissen und Fähigkeiten einbringen kann, um ein gemeinsames Ziel zu erreichen. Das Management sollte nur die groben Rahmenbedingungen abstecken, Risiken absichern und Hindernisse beseitigen. Und somit dem Team die Autonomie geben, die Aufgabe selbständig zu lösen. So gesehen kann man auch im realen Leben eine agile Methodik anwenden.
Zugegeben der direkte Vergleich hinkt manchmal etwas, aber die Grundprinzipien sind klar zu erkennen.
