Wie sollten wir Elemente aus Sprint Retrospektiven implementieren?

Ich empfehle, den Fokus Ihrer Retrospektiven zu ändern. Anstatt Ideen zu finden, konzentrieren Sie sich darauf, wie Sie eine einzelne Idee umsetzen können. Angenommen, Sie haben drei Teile des Meetings: Ideen finden, was der nächste Schritt ist und wie dieser Schritt umgesetzt wird.

Im ersten Teil sammelst du Ideen – nichts Neues hier –, aber im zweiten Teil wählst du nur eine Idee aus, die das Team im nächsten Sprint umsetzen wird. Im dritten Teil führen Sie ein Planungsmeeting ähnlich einer Sitzung durch, wie Sie diese Idee umsetzen können, und bringen das Ergebnis – die Aufgaben – zu Ihrem Scrum-Board. Es wird dringend empfohlen, diese Teile zeitlich zu planen , damit Sie genügend Zeit für den dritten Teil haben.

Mit diesem Ansatz haben Sie Ihren Fokus und Ihr Tracking. Es ist nicht nötig, täglich über den Fortschritt der Idee zu sprechen, aber es kann sehr hilfreich sein. Es kann auch helfen, die erstellten „Ideenaufgaben“ mit einer anderen Farbe in das Sprint Backlog zu stellen, aber dieser Trick ist teamabhängig.

Wenn Sie die Verbesserungen nicht auf Ihrem Scrum Board haben, sind sie nicht sichtbar, und das bedeutet, dass sie nicht existieren (ja, Sie können Verbesserungen auf Ihrem Scrum Board haben).

Budgetierung ist eine interessante Frage. Ein guter Product Owner weiß, dass kontinuierliche Verbesserungen in Scrum entscheidend sind – das Framework dreht sich um kontinuierliche Verbesserung – es ist also keine Frage, ob man sie hat oder nicht. Wenn Sie immer noch Probleme haben, müssen Sie mehr Coaching durchführen und den Menschen helfen, die Bedeutung kontinuierlicher Verbesserungen auf jeder Ebene zu verstehen. Off-the-Record ist keine gute Idee , da dann keine wirkliche Transparenz mehr besteht, was letztendlich zu Misstrauen zwischen dem Product Owner und dem Scrum Team führt.

Retrospektiven dienen der Prozessverbesserung

Der Zweck einer Retrospektive in Scrum besteht darin, den Prozess des Teams zu „prüfen und anzupassen“. Es ist nicht als Brainstorming-Sitzung für Produktideen oder zum Generieren von Benutzergeschichten gedacht, die die Leute auf dem Taskboard sehen möchten – es geht darum, den internen Prozess des Teams zu verbessern, um mehr von dem zu tun, was funktioniert, und weniger von dem, was nicht funktioniert .

Beispielsweise kann Ihr Team entscheiden, dass es die „Definition of Done“ überarbeiten muss. Oder vielleicht entscheiden sie, dass sie die Art und Weise, wie sie verzweigen und den Quellcode zusammenführen, umgestalten oder einen Continuous-Integration-Server zum Workflow hinzufügen müssen.

Alles, was innerhalb des Teams ist, geht in das Sprint Backlog (nicht das Product Backlog) und erfordert daher keinen Konsens außerhalb des Teams. Wenn Ihre Retrospektive jedoch Prozessprobleme identifiziert, die externe Effekte sind (z. B. die Notwendigkeit von Mitteln für einen neuen CI-Server oder anhaltende Fehler im Zusammenhang mit Übergaben zwischen Teams), muss natürlich die größere Organisation auf die Probleme aufmerksam gemacht werden .

Probleme sichtbar machen

Bei der Retrospektive geht es darum, Probleme sichtbar zu machen und dem Team den Spielraum zu geben, sich selbst um eine Lösung herum zu organisieren. Wenn Ihre Unternehmenskultur es dem Scrum-Team jedoch nicht wirklich erlaubt, Probleme zu lösen, hat das Team das Recht und die Verantwortung , die Sichtbarkeit des Problems zu erhöhen und es dann direkt in den Schoß des Managements fallen zu lassen.

Wenn beispielsweise das Fehlen eines CI-Servers von Ihrem Team als Prozessengpass identifiziert wird, muss dieses Problem mit der Organisation besprochen werden. Wenn diejenigen, die das Geld in der Hand halten, sagen „Verzicht“, dann ist das eine Geschäftsentscheidung, mit der sie leben müssen – die Aufgabe des Teams besteht einfach darin, die Kosten dieser Geschäftsentscheidung vollständig sichtbar zu machen.

Das bedeutet, dass niemand unbezahlte Überstunden macht, indem er Integrationstests manuell durchführt, oder Integrationsarbeit „von der Stange“ macht. Wenn es Arbeit ist, geht es an die Tafel!

Wenn die Organisation Nein zu CI sagt, werden Merge- und Integrationstests einfach zu expliziten Geschichten im Sprint-Backlog, die:

1. Schätzung erfordern;
2. verbrauchen Zeit und Mühe; und
3. Ressourcen, Arbeitsstunden und Story Points von neuen Funktionen wegleiten.

Die Tatsache, dass diese zusätzlichen Aufgaben die Kapazität für Product-Backlog-Einträge reduzieren, ist weder gut noch schlecht; Es ist einfach eine natürliche Folge der Geschäftsentscheidung, und solange es sowohl für das Team als auch für die Organisation transparent und sichtbar ist, liegt die Verantwortung, reduzierte Kapazitäten zu akzeptieren oder die Situation zu ändern, ausschließlich beim Management.

Die Rolle des Scrum Masters

Die Rolle des Scrum Masters bei all dem besteht darin:

1. Moderieren Sie die Scrum-Retrospektive.
2. Ermutigen Sie das Team, interne Prozessverbesserungen selbst umzusetzen.
3. Aktualisieren Sie Prozessartefakte wie das Sprint Backlog oder das „Definition of Done“-Poster, um alle vom Team vereinbarten Änderungen widerzuspiegeln.
4. Erleichtern Sie die Kommunikation mit der externen Organisation, wenn Probleme umfassender sind als der interne Prozess des Teams.

Und das ist es. Du bist kein Babysitter. Ihre Aufgabe ist es nicht, die Ergebnisse der Retrospektive zu „verwalten“, Leuten nachzujagen, um sicherzustellen, dass sie Änderungen umsetzen, oder irgendetwas anderes, das nach Mikromanagement riecht. Sie sind Moderator, Prozessreferent und Coach; verlieren Sie nicht die Kernrolle, die es Scrum als Prozess ermöglicht, reibungslos zu funktionieren.

Ich sehe und erlebe nur zwei Arten von Verbesserungen, die aus Retrospektiven (oder anderen Lessons Learned-Sitzungen) hervorgehen:

• Die Verbesserungsidee kann innerhalb Ihres Teams (und damit Ihres Budgets) bearbeitet werden und sollte nur dann umgesetzt werden, wenn sich daraus ein direkter Nutzen für Ihr Team und damit für den Gesamtfortschritt Ihres Projekts ergibt. Die Nachbereitung beginnt beim nächsten Stand-up-Meeting. Du kannst es nur umsetzen, wenn es einen echten Mehrwert für dein Team hat, sonst macht es das Team nicht. Lassen Sie es in diesem Fall fallen.

Wenn Sie erfolgreich sind, können Sie diese Lesson Learned an den Rest Ihrer Organisation weitergeben.

• Die Verbesserung liegt außerhalb der Kompetenz oder Kapazität Ihres Teams (z. B. organisatorische Prozesse oder Tool-abhängig oder ...). Hier können Sie nichts tun, außer zu versuchen, andere (z. B. Ihren Manager) davon zu überzeugen, dass dies Ihre (und möglicherweise andere) Teams erheblich verbessern, die Kosten senken, die Lieferung beschleunigen usw. würde. Dies liegt außerhalb Ihres Projektbudgets, es sei denn, es wird entschieden, dass Sie es hinzufügen können Dies ist ein zusätzlicher Umfangspunkt für Ihr Team, wobei die Auswirkungen auf das verfügbare Budget zu berücksichtigen sind. Andernfalls liegt es völlig außerhalb Ihres Teambereichs und Sie können die zuständigen Personen nur an seine Wichtigkeit erinnern (bei neuen Fällen, zusätzlichen Abfallzahlen usw.) und regelmäßig überprüfen, ob es Fortschritte gibt.