Wie überzeuge ich mein Team, die Sprintdauer von drei Wochen auf zwei Wochen zu reduzieren?

Soweit ich Ihre Situation verstanden habe (Sie haben es in den Kommentaren erklärt), ist das Problem, das Sie zu lösen versuchen, das fehlende Feedback von der Bestellung. Es scheint, dass Sie es nur am Ende des Sprints bekommen.

Wer mehr Feedback will, muss den Sprint nicht unbedingt verkürzen. Sie könnten

• Führen Sie eine PO-Annahme als Teil der Definition of Done ein, damit die PO die User Story überprüft, wenn sie als implementiert gilt
• Erstellen Sie kleinere User Stories, die in kürzerer Zeit implementiert werden können

Während mein Bauchgefühl mir sagt, dass Ihr Team von kürzeren Sprints profitieren könnte, möchte ich warnen, dass Sie sehr präskriptiv sind. Das heißt, Sie haben bereits entschieden, dass zweiwöchige Sprints Ihre Probleme lösen werden, und Sie versuchen jetzt, die Leute an Bord zu holen. Auf lange Sicht ist es für das Team besser, wenn Sie ihm helfen, gute Gewohnheiten zu entwickeln, Probleme im Team selbst als Gruppe zu erkennen und zu lösen.

Wenn das Problem beispielsweise darin besteht, dass die Stories die Anforderungen des Product Owners nicht erfüllen, fragen Sie nach dem Grund. Vielleicht sagen sie, dass sie eine Geschichte zu Ende bringen, und dann sagt der Product Owner, dass es falsch ist. Vielleicht liegt das daran, dass es bei der Sprintplanung kein richtiges Verständnis gibt, oder vielleicht müssen Sie öfter Kontakt zwischen der PO und den Entwicklern aufnehmen. Fragen Sie das Team nach einer Idee, wie es verbessert werden kann, und Sie können ein Experiment für ein oder zwei Sprints einrichten, um es auszuprobieren. Experimente sollten klar darüber sein, welche Maßnahmen ergriffen werden, was Sie damit lösen möchten und auf welche Erfolgs- und Misserfolgsbedingungen zu achten ist.

Da Sie längere Sprints haben, sollten Sie vielleicht alle paar Tage oder einmal pro Woche nachfragen, wie es Ihnen geht. Wenn ich raten müsste, denke ich, dass Ihre Sprints irgendwo in diesem Prozess in den nächsten Monaten kürzer werden, nur weil 3 Wochen für die meisten Gruppen ein ziemlich langer Sprint sind, aber wer weiß – das VS-Team von Microsoft führt 3-wöchige Sprints durch und scheint damit gut zurechtzukommen.

Teams mögen manchmal die Idee kürzerer Sprints nicht, da sie befürchten, dass ein größerer Prozentsatz ihrer Zeit in Meetings verbracht wird. Aber die Länge der Sprintzeremonien sollte proportional zur Länge des Sprints sein, damit sie nicht mehr Zeit als zuvor aufwenden.

Es kann auch technische Probleme geben. Einige Teams befürchten, dass 2 Wochen nicht ausreichen, um technisch kompliziertere Geschichten fertigzustellen. Hier kommt die Bedeutung der Aufschlüsselung von Geschichten ins Spiel.

Versuchen Sie herauszufinden, ob diese Bedenken (oder andere) im Team vorhanden sind. Wenn dies der Fall ist, arbeiten Sie sie durch und bauen Sie Vertrauen im Team auf, dass kürzere Sprints funktionieren können. Denken Sie jedoch daran, dass es am Ende des Tages die Entscheidung des Teams ist. Sie müssen sie also mit vernünftigen Argumenten überzeugen.

TL; DR

Die Rolle des Scrum Masters besteht darin, das Entwicklungsteam und den Product Owner zu ermutigen, zusammenzuarbeiten, um Probleme kooperativ zu lösen, anstatt zu versuchen, das Problem durch autoritäre Verfügungen zu lösen. Verwandeln Sie ein echtes Problem (z. B. schlechte Rückkopplungsschleifen) nicht in ein X/Y-Problem , indem Sie davon ausgehen, dass die Ursache in Ihrer Sprintlänge liegt. Dies ist ein logischer Fehlschluss, höchstwahrscheinlich eine Variante von post hoc ergo propter hoc .

Die eigentliche Ursache für Ihre schlechten Feedbackschleifen ist der Mangel an Routine oder kontinuierlichem Engagement des Product Owners, was eine Voraussetzung für eine funktionierende Scrum-Implementierung ist. Dies anzugehen und effektiv zu umgehen, sollte der Schwerpunkt der Problemlösungsbemühungen Ihres Teams sein. Änderungen an der Sprintlänge sind nur eine mögliche Lösung und möglicherweise nicht einmal die beste. YMMV.

Ihre Problemstellung

PO befindet sich an einem verteilten Ort und in einer anderen Zeitzone ... Wie überzeuge ich mein Team, das in einem dreiwöchigen Sprint arbeitet, an einem zweiwöchigen Sprint zu arbeiten? Die Idee für mich ist, schneller Feedback vom Product Owner zu erhalten. [sie]

Ihre Probleme, identifiziert

Sie haben die folgende Problematik formuliert:

1. Mangelndes tägliches Engagement des Product Owners. Dies ist ein Scrum-Nein-Nein.
2. Fehlendes zeitnahes Feedback zu Produktinkrementen, das offenbar nur während des Sprint Reviews eingeht.
3. Ein Team, das in kürzeren Iterationen keinen Vorteil für das Team sieht.

Ihre möglichen Lösungen

Um die Probleme anzugehen, die Sie haben, müssen Sie die Idee fallen lassen, das Team zu „überzeugen“, etwas zu tun, von dem es glaubt, dass es nicht in seinem besten Interesse ist. Das ist nicht agil; es ist ein Überbleibsel des altmodischen Command-and-Control-Projektmanagements. Stattdessen sollten Sie erwägen, die identifizierten Probleme in einer Sprint-Retrospektive anzugehen und Lösungen vom gesamten Team, einschließlich des Product Owners, zu erfragen.

Pragmatische Lösungen können sein:

• Kleinere Sprint-Backlog-Aufgaben, die der INVEST-Mnemonik folgen . Dies bietet dem Product Owner mehr Inspektions- und Anpassungspunkte innerhalb jeder Iteration.

  Storys müssen möglicherweise weiter zerlegt und Sprint-Backlog-Aufgaben gekürzt werden, damit sie in einen messbareren Inspektionszyklus von 0,5 bis 2,0 Tagen passen.

• Sicherstellen, dass der Product Owner während definierter Kernzeiten erreichbar ist.

  Die Verwendung von Skype, Telefon, E-Mail oder irgendetwas anderem, das eine bidirektionale Kommunikation zwischen dem Entwicklungsteam und dem Product Owner ermöglicht, würde es dem PO ermöglichen, Fragen zu beantworten und Implementierungsdetails mit dem Team auszuhandeln. Dies ist auch dann möglich, wenn der PO nicht beim Team sitzen kann.

• Bieten Sie dem Product Owner die Möglichkeit, frühzeitig und häufig Feedback zu Inkrementen zu geben.

  Als ein Beispiel könnte der PO vielleicht Aufgaben oder Stories als Teil der Definition of Done innerhalb des Sprints inspizieren, anstatt nur am Ende während der Sprint-Reviews.

• Identifizieren Sie die Gründe, warum das Entwicklungsteam kürzere Iterationen nicht für vorteilhaft hält , und gehen Sie diese Dinge gemeinsam an.

  Einige gängige Beispiele können sein:

  • Geschichten, die nicht klein genug sind, um in eine kürzere Iteration zu passen.
  • Eine Definition of Done, die Aufgaben enthält, die eine kürzere Iteration unpraktisch machen würden.
  • Ressourcenbeschränkungen, die kürzere Iterationen unhaltbar machen würden.
  • Höherer Framework-Overhead aufgrund erforderlicher Scrum-Zeremonien, die einen größeren Prozentsatz der verfügbaren Zeit in Anspruch nehmen. (Hinweis: Es gibt einen verwandten Beitrag , in dem dieser Overhead im Detail erörtert wird. Die Erkenntnis daraus ist, dass kürzere Iterationen engere Feedback-Schleifen bieten, jedoch auf Kosten eines höheren Prozess-Overheads.)

Die Rolle des Scrum Masters besteht darin, als Framework-Schiedsrichter und Prozesscoach zu fungieren und dem Team auf der Grundlage seiner oder ihrer bisherigen Erfahrung Ratschläge zu erteilen, nicht darin, Implementierungsdetails über die vom Framework vorgeschriebenen Zeremonien hinaus vorzuschreiben. Stellen Sie sicher, dass Sie das Entwicklungsteam und den Product Owner ermutigen, zusammenzuarbeiten, um das Problem zu lösen, anstatt zu versuchen, das Problem selbst durch autoritäre Dekrete zu lösen.

Mit der Sprintlänge zu spielen ist eine gute Idee, wenn Sie Probleme haben. Es ist zwar eine gute Sache, frühzeitig Feedback zu erhalten, aber Sie sollten sich auch die Bedenken ansehen, die das Team mit der neuen Sprintlänge voraussieht.

Wären sie in der Lage, die Geschichten klein genug zu schneiden, um sie in zwei Wochen fertigzustellen? Sie haben auch gesagt, dass es nicht viel Automatisierung gibt, was bedeuten würde, dass das Testen vorerst länger dauern würde. Versuchen Sie, nach einer Lösung für diese Aspekte zu suchen, und Sie können das Team möglicherweise überzeugen.

In der Vergangenheit mussten wir vor allem wegen schlechter Einschätzungen und Planabweichungen auf kürzere Sprints umstellen.

Als wir die Dauer und damit den Umfang reduzierten, verbesserten sich die Schätzungen und die Abweichungen waren geringer (ich denke, je näher der Liefertermin rückt, desto konservativer schätzt man).

Wie auch immer, ich stimme anderen zu, wenn Sie vorhaben, die Dauer zu ändern:

• Tun Sie es, um Probleme zu lösen.
• Holen Sie zuerst die Leute an Bord und planen Sie die Änderung später.