Es ist nur eine andere Art der Planung
Dieser Aussage aus dem Scrum Guide stimme ich voll und ganz zu: „In komplexen Umgebungen ist unbekannt, was passieren wird“ – Scrum Guide 2020.
Scrum ist ein Framework zur Wertschöpfung in komplexen Umgebungen.
Damit ist die Sache geklärt, oder? Wenn Sie nicht wissen, was passieren wird, wissen Sie auch nicht, was Sie tun müssen. Sie können keinen Plan erstellen. Ende des Artikels.
Aber so einfach ist es nicht. Und mehr noch: Es stimmt nicht. Sie KÖNNEN einen langfristigen Plan erstellen, auch wenn Sie nicht wissen, was passieren wird. Es ist eine andere Art von Plan, vorallem ist es eine andere Art, darüber zu denken. Und da liegt der Fehler.
Komplexe Umgebungen und traditionelle Pläne
Ein traditioneller Plan ist ergebnisorientiert. Sie zerlegen die Arbeit in kleinere Teile und planen diese entsprechend. Sie wissen, was Sie tun müssen, entweder weil es klar ist oder weil Sie es durch eine gründliche Analyse herausfinden.
Möglicherweise sammeln Sie unterwegs neue Erkenntnisse, diese haben jedoch keinen großen Einfluss auf Ihren Plan. Sie können dem Plan treu bleiben, indem Sie kleine Anpassungen vornehmen. Das Unterfangen ist relativ unkompliziert.
Herkömmliche Pläne funktionieren nicht, wenn Sie nicht wissen, was zu tun ist. Wenn Ihnen eine gründliche Analyse nicht weiterhilft und Sie durch das Tun lernen müssen. In komplexen Umgebungen müssen Sie Experimente durchführen, um Fortschritte zu erzielen.
Ziel statt Output ist die Lösung
Wir haben gerade festgestellt, dass man in komplexen Umgebungen nicht weiß, was passieren wird. Man weiß nicht, was man tun muss, um erfolgreich zu sein. Der Output kann kein Mittel sein, um unseren Fortschritt zu planen und zu messen.
Es gibt eine Alternative. Unabhängig von der Art der Produktumgebung – ob kompliziert oder komplex – gibt es immer einen Grund, diese Reise anzutreten. Es gibt immer ein Ziel, das Sie erreichen möchten. Sie möchten beispielsweise das Benutzererlebnis verbessern, neue Märkte erschließen oder das Produkt stabilisieren.
Ihre Maßnahmen sind erfolgreich, wenn Sie Ihr Ziel erreichen, unabhängig davon, ob Sie alles geschafft haben, was Sie sich vorgenommen haben. Wenn Sie alle Aufgaben zur Verbesserung der UX Ihres Produkts abgeschlossen haben und Ihre Kunden dennoch unzufrieden sind, haben Sie Ihr Ziel nicht erreicht.
In komplexen Umgebungen kennen Sie Ihr Ziel. Sie kennen die Ergebnisse, die Sie erreichen möchten. Sie können auch beurteilen, ob Sie Ihrem gewünschten Ziel näher kommen. Ihr Ziel, Ihr gewünschtes Ergebnis, bestimmt Ihre Entscheidungen. Beim Militär nennt man dies die Absicht des Kommandanten: Absicht des Kommandanten. Das Ziel ist größer als der Plan (danke, Harry S. Long ).
Das Ziel und wie Scrum damit umgeht
Bei Scrum geht es darum, Ihre Ziele zu erreichen. Aus diesem Grund ist das Produkt-Backlog auf das Produktziel ausgerichtet. Das wurde bisher nicht richtig verstanden.
„Das Produktziel ist das langfristige Ziel für das Scrum-Team.“ – Scrum Guide 2020
Dieses Produktziel enthält den gewünschten zukünftigen Zustand des Produkts. Es sollte klar sein, wie das Team und seine Stakeholder feststellen können, ob der zukünftige Zustand des Produkts erreicht wird. Es kann auch ein Fälligkeitsdatum enthalten. Hier sind einige
Beispiele für Produktziele:
„Am Ende des zweiten Quartals haben wir die Kundenzufriedenheitsrate für Produkt X von 50 % auf 75 % gesteigert“
„Innerhalb von zwei Monaten haben wir die Zahl der vorrangigen Vorfälle von 15 pro Woche auf 2 pro Woche reduziert.“
Der alternative langfristige Plan
Ihr Produktziel ist die Verpflichtung des Scrum-Teams. Das Produkt-Backlog enthält alle Dinge, die das Team seiner Meinung nach erreichen muss, um dem Produktziel näher zu kommen. Das Product Backlog ändert sich ständig. Immer wenn das Team neue Erkenntnisse gewinnt, werden Elemente hinzugefügt, entfernt oder geändert. Das Scrum-Team verfeinert das Product Backlog ständig.
Das Product Backlog und sein Produktziel bilden den langfristigen Plan zur Verbesserung des Produkts. Die Product Backlog-Elemente dienen als Mittel, um dem Produktziel näher zu kommen. Nicht das Product-Backlog ist das Ziel, sondern die Verpflichtung da drin. Aber nicht auf traditionelle Weise.
Ein Product Backlog kann keinen vollständigen Plan zur Erreichung des Produktziels enthalten. Das macht keinen Sinn, weil Sie es nicht wissen oder vorhersehen können. Das Wichtigste ist, den Fortschritt in Richtung des Produktziels zu verstehen und eine Vorstellung davon zu haben, was das Team im nächsten Sprint erreichen will. Also was es unternimmt pder unterlässt, um dieses Ziel zu erreichen. Ein Product Backlog kann superkurz und/oder absichtlich vage sein. Das Abschließen der Elemente im Product Backlog garantiert nicht, dass das Team dem Produktziel näher kommt. In komplexen Umgebungen ist regelmäßiges Überprüfen unerlässlich. Sie müssen mindestens bei jedem Sprint überprüfen.
Die Bedeutung des Sprint Reviews
Beim Sprint Review wird das Ergebnis des Sprints überprüft. Das Team und seine Stakeholder müssen die folgenden Fragen beantworten:
„Was haben wir aus unseren Experimenten gelernt und wie wirkt sich dies auf den Fortschritt in Richtung des Produktziels aus?“
Sie untersuchen die Produkterweiterungen und alle anderen neuen Erkenntnisse, die Auswirkungen haben könnten. Diese Erkenntnisse könnten Benutzerfeedback, technologische Entwicklungen, neue Möglichkeiten und Informationen zur Konkurrenz sein.
Diese Überprüfung führt zu Anpassungen am Product Backlog. Das Team wird Änderungen vornehmen, um die Chancen zur Erreichung des Produktziels zu maximieren. Zumindest sollten sie eine gute Vorstellung davon haben, was sie im nächsten Sprint erreichen möchten. Das Sprint Review ist das formelle Ereignis zur Aktualisierung des Product Backlogs. Natürlich beschränken Sie sich nicht auf dieses Ereignis. Sie verfeinern das Product Backlog mit jeder (!!) Erkenntnis, die Ihre Ansicht darüber verändert, wie Sie die Chancen zur Erreichung des Produktziels maximieren können.
Planen auf Sprint-Ebene
Ich finde es wichtig zu betonen, dass detaillierte Pläne auf Sprint-Ebene ebenfalls nicht funktionieren. Aus diesem Grund erstellen Teams ein Sprint-Ziel. Wird dieser Schritt unterlassen, ist das Product Backlog und Scrum selbst schon in Frage gestellt. Die ausgewählten Product Backlog-Elemente sind eine Prognose des besten Weges, das Sprint-Ziel zu erreichen. Bei Daily Scrums geht es um den Fortschritt in Richtung des Sprint-Ziels und um die Änderung des Plans, falls erforderlich. Es geht nicht darum, alle geplanten Elemente fertigzustellen.
Fazit: Ändere die Erzählung!
Scrum arbeitet mit langfristigen Plänen. Es ist falsch zu behaupten, dass dies nicht der Fall sei. Tatsächlich schadet dieser Glaube dem Ruf von Scrum. Dies ist ein Grund, warum Unternehmen nach anderen „agilen“ Wegen suchen, um Produkte zu erstellen – und auch wieder scheitern. Wege, bei denen mehrere Sprints im Voraus geplant werden. Was in komplexen Umgebungen nicht funktioniert – und nicht funktionieren kann.
Die Erzählung muss sich vom Ergebnis zu den Zielen ändern. Sobald Sie dies getan haben, können Sie in Scrum langfristige Pläne in Form des Product Backlogs erstellen.
Diese Pläne drehen sich um das Produktziel, das langfristige Ziel eines Scrum-Teams und den zukünftigen Zustand des Produkts. Das Produktziel dient als Verpflichtung für die Elemente im Produkt-Backlog. Teams und Stakeholder sollten sich auf das Produktziel konzentrieren. Sie sollten besprechen, wie sie Experimente durchgeführt haben, um neue Erkenntnisse zu gewinnen und herauszufinden, ob sie dem Produktziel näher gekommen sind.
Komplexe Umgebungen erfordern einen Ansatz, der ein Ziel definiert, häufige Überprüfung und Anpassung sowie ständige Neuplanung erfordert. Der Schlüssel zum Erfolg ist eine enge Zusammenarbeit zwischen dem Team und seinen Stakeholdern. Dies erfordert unermüdliches Engagement – ERST an dein Zielen, dann am Product Backlog.