Wer einem Scrum-Team bei der Planung eines Sprints mal über die Schultern geschaut hat, kennt das Ritual: Das Entwicklungsteam entscheidet darüber, welcher Umfang aus dem Product Backlog für den Sprint eingeplant wird. Diese Entscheidung wird „Commitment“ oder „Forecast“ genannt - im Deutschen finde ich das Wort „Zusage“ passend.
In einem unter Zeitdruck stehenden Projekt habe ich das Ritual besonders in Erinnerung: Nahte das Commitment, verließ die Product Ownerin den Raum und tigerte erwartungsvoll den Flur auf und ab. Ihre Sorge, das Entwicklungsteam könne „auf Nummer sicher“ gehen und eher weniger als mehr in den Sprint nehmen, war ihr abzulesen. Das Entwicklungsteam wägte unterdesssen ab, ob diese eine User Story aus dem Backlog noch in den Sprint passe. Unterschiedliche Ansichten wurden diskutiert. Nach einer Weile war die Entscheidung gefallen und das Entwicklungsteam rief die Product Ownerin wieder hinein. Diese hatte die Entscheidung zu akzeptieren - in diesem Fall mit Enttäuschung, hatte es die eine Story doch nicht mehr in den Sprint geschafft.
Das Commitment in Scrum verdeutlicht einen Mechanismus, der als Pull oder Pull-Prinzip bekannt ist. Das Entwicklungsteam kontrolliert die Menge an Aufgaben (in diesem Fall User Stories), die aus dem Product Backlog in den Sprint genommen werden. Der Antagonist des Pull-Prinzips ist das Push-Prinzip. Wir würden in unserem Beispiel von Push sprechen, wenn unsere Product Ownerin den im Sprint zu erledigenden Umfang vorgäbe.
Wie aber lässt sich das Pull-Prinzip prozesstechnisch darstellen? Um dies zu verstehen, müssen wir uns zwei Begriffe näher anschauen:
Die Flussrichtung der miteinander verknüpften Abläufe oder Aufgaben (Tasks): In unserem Beispiel entsteht als erstes ein priorisiertes Product Backlog mit einzelnen Aufgaben (in Form von User Stories). Diese Aufgaben werde dann vom Entwicklungsteam für den Sprint ausgewählt, anschließend im Sprint bearbeitet und zuletzt als Produkt-Inkrement fertig gestellt und freigegeben.
Die Richtung der Flusskontrolle (Flow Control Direction): Handeln wir nach dem Pull-Prinzip, dann läuft die Richtung der Flusskontrolle entgegen der Flussrichtung. Handeln wir dagegen nach dem Push-Prinzip, sind Flussrichtung und Flusskontrolle gleich gerichtet.
Das Commitment in der Sprint-Planung lässt sich dann wie folgt visualisieren:
Die Anwendung des Push-Prinzips hat einige Vorteile
Aufgaben werden bedarfsgerecht in die Umsetzung gegeben. Dinge werden nur dann aus dem Backlog „gezogen“, wenn im Sprint noch Kapazitäten dafür frei sind.
Entscheidungen werden dort getroffen werden, wo das Wissen ist. Das Entwicklungsteam kann im Zweifel am besten beurteilen, wie viel es innerhalb eines Sprints schaffen kann.
Das Pull-Prinzip nimmt die Eigenverantwortung ernst: Indem das Entwicklungsteam eine verbindliche Zusage macht, steht es für die Erreichung des selbst gesteckten Ziels ein.
Es ist manchmal schwer, sich auf das Pull-Prinzip zu verlassen. Im oben genannten Beispiel ist es Product Ownerin, die auf die Zusagen des Entwicklungsteam angewiesen ist.
Wenn ein hoher Termindruck vorhanden ist, kann es verlockend sein, die Menge an zu erfüllenden Aufgaben in die Umsetzung zu „drücken“ und das Push-Prinzip anzuwenden. Einige Methoden aus dem Projektmanagement funktionieren genau so. Sie rechnen vom Zieltermin die zu erledigenden Aufgaben zurück. Das Entwicklungsteam hat dann ein Pensum zu erfüllen - und muss schauen, wie es das termingerecht schafft. So entstehen Ziele, an deren Erreichung irgendwann keiner mehr so richtig glaubt.
Das Pull-Prinzip leistet einen Beitrag zur Transparenz und zu einer offenen Kommunikation. Schon in den ersten Sprints wird sichtbar, was tatsächlich möglich ist (und was nicht). Und das wiederum ist eine gute Grundlage, um gemeinsam daran zu arbeiten, die Produktivität zu verbessern (oder die Ansprüche herunter zu schrauben).
Foto von Diego Madrigal von Pexels
Comments