Die Geschichte von Scrum ist eine Geschichte voller Missverständnisse. Heute werfen ich mal einen Blick auf das, wozu in einigen Organisationen das Sprint Review verkommen ist, eine Sprint Demo mit Akzeptanz-Celebration. Für heute habe ich mir mal vorgenommen, von der positiven Seite zu argumentieren, warum das eine schlechte Idee ist. Mal gucken, wie gut mir das gelingt.
empirische Prozesskontrolle
Scrum im Speziellen und agil im Allgemeinen ist optimiert für komplexe Unterfangen. Signifikant für eine komplexe Umgebung ist, dass man Dinge nicht vorhersehen kann, hinterher – so der Volksmund – ist man aber stets schlauer. Fussball ist beispielsweise so eine komplexe Umgebung. Wir wissen nicht, wie die Fussball-Weltmeisterschaft ausgehen wird. Jede Person, die die Fussball-Weltmeisterschaft verfolgen wird, kann uns hinterher allerdings ihre Perspektive offenbaren, warum die Dinge so gekommen sind, wie sie gekommen sind.
Scrum baut hier auf empirischer Prozesskontrolle, um in einer komplexen Umgebung handlungsfähig zu bleiben. In kurz basiert empirische Prozesskontrolle auf drei Säulen:
- Transparenz: hier weise ich gerne darauf hin, dass es hierbei um ehrliche Transparenz zu unseren Fortschritten geht. Der Bundestrainer wird vermutlich keine gute Spielvorbereitung leisten können, wenn seine Daten aus den letzten Spielen der Kreisliga am anderen Ende der Welt zieht.
- Inspektion: wir bewerten regelmäßig, wo wir stehen, anhand der ehrlichen Transparenz, die wir geschaffen haben.
- Anpassung: basierend darauf, wo wir stehen, planen wir die nächsten Schritte.
In der Produktentwicklung ist es leider häufig so, dass uns Stakeholder und Benutzerinnen nicht vorher sagen können, was sie genau haben möchten. Basierend auf ersten Prototypen und was sonst noch im Markt passiert ist, können sich ihre Vorstellungen ändern. Mit dem Sprint Review versuchen wir in Scrum, die Lernschleife über das Produkt regelmäßig zu schließen, damit wir in jedem Sprint sicherstellen können, dass wir gerade an dem weiterhin wichtigsten arbeiten – auch wenn sich die Welt weiter dreht.
Sprint Review
Übertragen auf das Sprint Review gibt es eigentlich nur zwei Hauptpunkte, die wir auf jeden Fall erledigen müssen, damit wir dem Prinzip der empirischen Prozesskontrolle hier folgen.
Zum einen müssen wir Feedback von den anwesenden Stakeholdern zum derzeitigen Stand des Produktes einsammeln und potentiell mit unseren früheren Ideen im Product Backlog verschmelzen, einsortieren, priorisieren, etc.
Damit wir Feedback zum Produkt bekommen können, müssen wir ehrliche Transparenz über das Produkt herstellen. Je näher diese Vorstellung an die Einsatzzwecke der Anwesenden anknüpft, desto besseres Feedback können wir von den Anwesenden erwarten. Führe ich durch das Produkt in einer Bildschirmpräsentation durch, ist das sicherlich ein guter Start. Bei einigen Smartphone-Apps habe ich auch Reviews erlebt, in denen einige Mobiltelefone mit dem aktuellen App-Stand auf dem Tisch lagen und die Anwesenden direkt die App benutzen durften.
Das wichtigste im Sprint Review ist, dass wir in einer komplexen Umgebung Feedback von Usern und Stakeholdern bekommen. Alles andere sollte deshalb auch zweitrangig sein. Das bedeutet, wenn der Product Owner das Produkt vor der Auslieferung abgenommen haben muss, dann kann man versuchen, das im Sprint Review auch zu machen. Wenn diese Abnahme-Frage im Sprint Review aber zu sehr davon ablenkt, dass wir das Primärziel des Reviews, Feedback zum Produkt zu bekommen, verfehlen werden, dann sollten wir doch besser einen anderen Ort für diese Abnahme finden.
In einer Situation habe ich mal erlebt, dass im Sprint Review die Frage nach der Abnahme auftauchte. Damals hatte ein relativ neuer Entwickler das Feature, an dem er gearbeitet hatte, vorgestellt. Der Entwickler war keine zwei Monate in dem Scrum-Team tätig. In dem Sprint Review saß noch der CTO, der gleichzeitig auch der Vorgesetzte aller anwesenden Entwicklerinnen war. Die Situation hat von Grund auf einen Kern-Wert von Scrum verletzt: Respekt. Wenn das Feature tatsächlich nicht so umgesetzt wurde, wie sich der Product Owner das gewünscht hat, dann wäre ich als Entwickler doch froh gewesen, wenn ich diesen Umstand schon mal vorher erfahren hätte, bevor jetzt der Vorgesetzte dabei ist und ich dabei bloß gestellt werde. Für mich ist diese Situation sogar so respektlos, dass ich mir so eine Situation noch max. 1 weiteres Mal geben würde – und ansonsten innerhalb der Probezeit das Unternehmen wieder verlassen würde.
Mit dem Hintergrund der empirischen Prozesskontrolle sehen wir auch, dass die Abnahme des Produktes für die Zielerreichung des Sprint Reviews nicht essentiell ist. Ich wäre da viel eher an der Perspektive der anwesenden Stakeholder interessiert, inwiefern diese glauben, das Produkt könne so ausgeliefert werden, und falls nicht, was fehlt denn, dass wir das Feature für sie ausliefern können? Die Dinge, die daraufhin genannt werden, kommen in unser Product Backlog, wir priorisieren dieses gegen die schon vorhandenen Dinge, und gehen mit diesem angepassten Product Backlog in das kommende Sprint Planning. Vielleicht runden wir dann im kommenden Sprint die noch folgende Funktionalität ab, wenn sie gegenüber dem restlichen Zeug wichtig genug ist – vielleicht kommt das zu einem späteren Zeitpunkt. In jedem Fall müssen wir dafür die Abnahme des Features nicht im Sprint Review diskutieren.
Und ja, mir ist bewußt, dass da jetzt jede Menge Dinge sein können, weswegen wir jetzt am Ende des Sprint kein auslieferfähiges Produktinkrement haben, weil etwas nur halbrund und nicht ganz rund ist, usw. Für alle diese Fälle gibt es Entwicklungspraktiken, die dann sinnvoll werden, wie das Einbauen von Feature Flags, so dass ich noch nicht fertige Funktionen gezielt abschalten kann, aber trotzdem in der Lage bin, den derzeitigen Stand auszuliefern, z.B. Das ist für mich immer die Gelegenheit aus einem „das geht nicht“ ein „ich weiß noch nicht, wie das geht“ zu machen und zu einem teachable moment zu kommen.
