Ein zweiwöchiges Produktinkrement kann brauchbar, aber nicht sehr nützlich sein. Muss PO also an jeder Sprint-Demo teilnehmen?
Nehmen wir an, eine Funktion bezieht sich hauptsächlich auf das Hinzufügen einer neuen Funktion zu einem Backend. Wir brauchen ein paar Sprints, um diese Backend-Funktion zu implementieren und erst dann kann das Feature wirklich begutachtet werden. Ich nehme an, wir können einfach PO sagen, dass wir ein paar Sprints brauchen, um eine Demo vorzubereiten, anstatt in jedem Sprint kleinere, formelle Demos durchzuführen.
Muss PO also an jeder Sprint-Demo teilnehmen?
Der Product Owner sollte während des gesamten Sprints Einblick in die Arbeit des Teams erhalten.
Die Absicht der Sprint-Review-Zeremonie in Scrum ist nicht, den Product Owner über die Arbeit zu informieren, die das Team geleistet hat, sondern Stakeholder zu informieren, die nicht wie der Product Owner täglich mit dem Team involviert sind.
Außerdem ist der Sprint Review nicht nur eine Demo. Um aus dem Scrum Guide zu zitieren :
Das Sprint Review ist eine Arbeitssitzung und das Scrum Team sollte es vermeiden, es auf eine Präsentation zu beschränken
Wenn Sie Scrum verwenden, ist die Erwartung, dass das Scrum-Team „in jedem Sprint ein wertvolles, nützliches Inkrement“ erstellt. Vor den Überarbeitungen des Scrum Guide im November 2020 wurde der Begriff „potenziell veröffentlichbar“ verwendet.
Es gibt keine „Sprint-Demo“ in Scrum. Das Ereignis ist die Sprint Review. Eine Demonstration kann ein Bestandteil eines Sprint Reviews sein, aber sie ist mehr als eine Demonstration. Eine Demonstration kann eine Möglichkeit für die Stakeholder sein, zu überprüfen, was im Sprint erreicht wurde, aber das Sprint Review sollte Elemente enthalten, in denen die Stakeholder Änderungen in der Umgebung diskutieren und das Produktziel und das Product Backlog basierend auf den neuesten Informationen angepasst werden.
Wenn es „ein paar Sprints“ dauert, um genug zu implementieren, damit die Arbeit von den Stakeholdern überprüft und Feedback eingeholt werden kann, deutet dies auf andere Probleme hin. Es gibt jedoch nicht genügend Informationen, um auch nur ansatzweise zu verstehen, wo die Probleme liegen könnten.
Kurz gesagt , Scrum wird so erklärt (Hervorhebung von mir):
- Ein Product Owner ordnet die Arbeit für ein komplexes Problem in ein Product Backlog ein.
- Das Scrum-Team verwandelt eine Auswahl der Arbeit in einen Wertzuwachs während eines Sprints.
- Das Scrum-Team und seine Stakeholder überprüfen die Ergebnisse und passen sie für den nächsten Sprint an.
- Wiederholen
Die Idee hinter ausgeführten Sprints ist, dass Sie sie als Mindestrhythmus für die Bereitstellung funktionierender Software verwenden oder zumindest am Ende des Sprints etwas Nützliches zur Überprüfung haben. Dies ist das Produktinkrement (oder eine Reihe von Inkrementen, wenn Sie beispielsweise während des Sprints mehr liefern, indem Sie Praktiken wie Continuous Integration/Deployment/Delivery verwenden). Sie verwenden dann die Inkremente, um Ihre Strategie anzupassen und zu entscheiden, was als nächstes zu tun ist oder was als nächstes wichtig ist. Sie nutzen auch die Gelegenheit, eine Retrospektive zu machen, um zu sehen, wie Sie auch Ihre Arbeitsweise anpassen und verbessern können.
Je länger Sie warten, bis Sie etwas Nützliches bereitstellen, desto länger dauern die Inspektions- und Anpassungsschleifen und desto mehr Probleme oder Risiken können auftreten, bevor Sie sich anpassen können.
Ich habe viele Unternehmen gesehen, die Software entwickeln und Wert mit einem altmodischen Ansatz liefern, wie das Zusammenfügen von Dingen in jedem Quartal (bestenfalls) mit Mini-Wasserfällen zu Meilensteinen, mit Gantt-Diagrammen, die die Arbeit in horizontalen Schichten aufteilen, mit einer letzten Phase für die gesamte Arbeit integrieren usw., aber sie erwarten von ihren Teams, dass sie gleichzeitig Scrum durchführen. Was passiert, ist, dass sie Entwickler nur in Sprints arbeiten lassen, mit einer Reihe von Meetings, die alle frustrieren, weil sie bedeutungslos sind (da die Arbeit immer noch auf die gleiche alte Weise, aber anders erledigt wird), aber die Meetings müssen wegen Scrum abgehalten werden sagt es. Das ist nicht Scrum.
Wenn Sie Scrum machen wollen, dann versuchen Sie, seine Regeln zu befolgen.
Wenn Sie etwas anderes tun, das für Sie funktioniert, und Sie sich nicht an den Risiken oder Problemen stören, die während eines großen Entwicklungsaufwands mit einer entsprechenden langen Feedback-Schleife auftreten können, dann ist das auch in Ordnung. Nennen Sie es einfach nicht Scrum und zwingen Sie die Leute nicht, an Zeremonien teilzunehmen, die für sich genommen keinen Sinn ergeben, ohne dass die anderen Teile auch zusammenpassen.
Todd A. Jacobs
Daniel