Die Hügel-Karte: Eine revolutionäre Sichtweise auf die Arbeit im Sprint

Schon seit Jahren beobachte ich bei Scrum Teams dieses Phänomen: Die Einträge im Sprint Backlog bewegen sich tagelang gar nicht. Und dann wird in letzter Minute doch alles fertig. 

Es ist immer das Gleiche: Egal, wie gut der Scrum Master die Entwickler daran erinnert, ganz gleich, ob das Scrum Team viele oder wenige Tasks parallel im Sprint bearbeitet, unabhängig davon, wie klein die einzelnen Aufgaben im Sprint Planning gemacht wurden – Fortschritt zeigt sich nicht am Sprint-Board.

Das ist die Natur komplexer Arbeit.

Im Idealfall wird die Bearbeitungsdauer vorab geschätzt und die Arbeit in gleiche Stücke aufgeteilt. So kann sie gleichförmig über das Scrum-Board von „To do“ zu „Done“ wandern. Das kann jedoch nur funktionieren, wenn das Scrum Team bereits vor Arbeitsbeginn alle Informationen hat. Und wir haben nur dann alle Informationen über einen Arbeitsprozess, wenn die gleiche Arbeit immer wiederholt wird.

Produktentwicklung entspricht aber nicht Fließbandarbeit, sondern kreativer Arbeit. 

Es gibt immer wieder neue und unbekannte Probleme, die gelöst werden müssen. Es müssen neue Designs erstellt werden, Code an Stellen geändert werden, an welchen die Entwickler noch nie gearbeitet haben, und Nutzer bei Anwendungsfällen unterstützt werden, die so im System nie vorgesehen waren. 

Nach Ryan Singer ist komplexe Arbeit nicht linear, sondern gleicht einem Hügel. 

In seinem Konzept gibt es zwei Phasen:

1. Die erste Phase gleicht einem Anstieg. Sie ist von Unsicherheiten geprägt. Wir müssen verstehen, wie eine Idee zum Leben erweckt werden kann. Es gibt erste Ideen zur Umsetzung der Aufgabe, aber bislang keine Lösungen. Vieles ist noch unbekannt und muss erst noch in Erfahrung gebracht werden. 
    
2. Irgendwann erreichen wir einen Punkt bei der Arbeit, an dem es keine offenen Probleme mehr gibt. Nun sind alle Arbeitsschritte bekannt und alle Unbekannten beseitigt. Wir wissen, dass wir auf der Spitze des Hügels stehen, da wir jetzt auf der anderen Seite des Hügels den Weg hinab sehen können. Es geht jetzt nur noch darum, die bekannten Arbeitsschritte auszuführen und abzuschließen. Dies ist die zweite Phase der Arbeit. Sie gleicht einem Abstieg. 

Der Abstieg geht nicht nur schneller, sondern entspricht eher einer geradlinigen und planbaren Abarbeitung von Aufgaben. Daher können wir auch verlässlicher einschätzen, wie lange es noch dauern wird, bis die Aufgabe abgeschlossen ist.

Wenn wir komplexe Arbeit als einen Hügel verstehen, erhalten wir drei Einsichten in die Arbeit von Scrum Teams.

Wie sollte ein Scrum-Board designt sein, um die Realität komplexer Arbeit transparent wiederzugeben?

Ein Scrum-Board sollte nicht aus Spalten bestehen, sondern einer Hügel-Karte gleichen. 

Bei komplexer Arbeit bildet es nicht die Realität ab, den Fortschritt bei der Erreichung des Sprint-Ziels anhand bereits erledigter Tasks zu bestimmen. Fortschritt ist keine Funktion von prozentualer Abarbeitung, sondern vom Grad der Unsicherheit. Die Hügel-Karte hilft uns, dies zu visualisieren, da die Arbeit nun vom „Unbekannten“ zum „Bekannten“ und vom „Bekannten“ zu „Done“ wandert.

Wie sollten wir mit Arbeiten umgehen, die am Ende des Sprints nicht fertiggestellt wurden? 

Die Hügel-Karte liefert auch Einsichten in unfertige Arbeiten:

Befindet sich die unfertige Arbeit bereits auf der Abstiegsseite des Hügels, dann besteht nicht mehr viel Risiko. Die Arbeit ist bereits gut verstanden und muss nur noch erledigt werden. Zeitliche Einschätzungen der Entwickler, wie lange es noch dauert, um die Arbeit abzuschließen, können als sehr glaubhaft bewertet werden. 

Befindet sich die unfertige Arbeit jedoch derzeit im Aufstieg zum Gipfel, dann sollten wir auf zeitliche Einschätzungen verzichten. Arbeit auf dem Weg zum Gipfel zeichnet sich dadurch aus, dass es noch ungelöste Probleme gibt. Es könnte sein, dass die Entwickler einfach noch nicht wissen, wie sie die Probleme lösen sollen. Und bis sie es herausgefunden haben, können Tage oder ganze Sprints vergehen. Deshalb müssen wir hier entscheiden, ob die Entdeckung einer Lösung weiter finanziert werden soll oder eben nicht.

Sollte im Refinement auch ein Lösungskonzept erarbeitet werden?

Es ist ein Irrglaube, dass Planung und Analyse ausreichen, um bei komplexer Arbeit bis zum Gipfel des Hügels zu gelangen – damit wir die Arbeit dann im Sprint geradlinig abarbeiten können.

Wir müssen uns die Codebasis ansehen, überlegen, welcher Algorithmus das Problem elegant löst, und erste Designentwürfe skizzieren. Die Elemente müssen bewegt werden, um zu sehen, wie am Ende alles zusammenpassen könnte.

Bei komplexer Arbeit erkennen wir den Gipfel erst, wenn wir oben stehen. Und wenn niemand im Team die Arbeit schon einmal getan hat, gibt es auch keine Karte, die uns vorab den Weg aufzeigt oder die wir als Plan verwenden können. Wir müssen den Weg selbst erst entdecken. Aber das sollte aus meiner Sicht nicht im Refinement passieren. Das Refinement ist nicht dazu gedacht, technische Lösungen zu finden und zu designen, sondern die Problemstellung aus der Sicht unserer Nutzer besser zu verstehen und zu beschreiben. Es geht darum, den möglichen Wert unserer Arbeit für das Produkt zu verstehen. So können wir am Ende entscheiden, ob wir die Wette eingehen wollen, dass sich die Verfolgung dieser neuen Idee positiv auf die Geschäftszahlen auswirken wird. Die Frage, die im Refinement beantwortet werden sollte, lautet: 

Glauben wir, dass es sich lohnt, in diese Idee einen Sprint zu investieren?

Am Ende dürfen wir nie vergessen:

In Softwareentwicklung ist alles möglich, aber nichts umsonst. 

Möchtest Du mehr erfahren?

Hoffentlich war dieser Artikel nützlich für Dich. Die Sichtweise auf komplexe Arbeit, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden. 

Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert. 

👉 Hier geht zur Anmeldung.