Wie sollten wir wiederkehrende oder immaterielle retrospektive Aktionspunkte implementieren und verfolgen?

Unser Produkt-/Tech-Team hat sich im letzten Jahr auf agiles Projektmanagement umgestellt, und wir halten tägliche Standups, wöchentliche Planungsmeetings und zweiwöchentliche Retrospektive-Meetings ab. Wir verwenden auch ein Kanban-Board.

Als Scrum Master des Teams habe ich versucht, die Retrospektiven umsetzbarer zu gestalten, da einige Teammitglieder darauf hingewiesen haben, dass wir am Ende oft dieselben Probleme diskutieren, die nicht gelöst werden. Ich mache mir Sorgen über die Auswirkungen auf die Moral und den Wunsch der Teammitglieder zur Teilnahme, also habe ich verschiedene Ansätze ausprobiert, um die Dinge konkreter zu machen, wie z auf das absolute Minimum (dh 1-2). Wir haben diese Elemente auch zu unserem Sprint-Board hinzugefügt, um sie sichtbar zu machen. Dies hat bei konkreten Ad-hoc-Aktionspunkten ziemlich geholfen.

Womit ich gerade zu kämpfen habe, sind das, was ich „immaterielle“ Aktionselemente nenne, dh Elemente, die mit Gewohnheiten oder Verhaltensänderungen verbunden sind und/oder wiederkehrender Natur sind. Hier sind einige Beispiele:

  • Wenn Sie eine PBI in Building ziehen , nehmen Sie sich etwas Zeit, um darüber nachzudenken, wie sie überprüft wird, damit keine Engpässe in der Spalte Bereit zur Überprüfung entstehen
  • Multiplizieren Sie beim Schätzen von Roadmap-Elementen mit 2, damit wir realistischere Schätzungen liefern
  • Zeichnen Sie während der Scoping-Phase Abhängigkeiten auf, damit wir die Arbeit besser planen können

Ich könnte das natürlich alles in ein Dokument packen und teilen, aber es würde wahrscheinlich im sprichwörtlichen Regal landen und nie umgesetzt werden. Selbst wenn diese Lösungen aus dem Team hervorgehen, um sehr reale Probleme anzugehen, bleiben sie meiner Erfahrung nach aufgrund ihrer immateriellen Natur schnell auf der Strecke, wenn es hektisch wird. Daher meine Frage: Wie stellen Sie sicher, dass diese Maßnahmen umgesetzt werden? Wie behalten Sie den Überblick?

Gute Frage, gut gestellt. Aber ich möchte Sie dringend bitten, sich das Thema „Roadmap-Items, multiplizieren mit 2“ noch einmal anzuschauen – das klingt nach einer potenziellen Fehlfunktion und vielleicht gibt es noch eine weitere Lernmöglichkeit zu entdecken. Viel Glück :)
@onedaywhen Die von Ihnen erwähnte Lösung sollte dem PO/PM signalisieren, dass die Menge an Arbeit, die derzeit in einem Quartal zusammengepfercht wird, zu viel für das ist, was das Team leisten kann, während es mit einem nachhaltigen Tempo arbeitet. Können Sie das, was Sie als Funktionsstörung gesehen haben, näher erläutern? Ich bin mir nicht sicher, was Sie meinen, und ich vermute, es könnte daran liegen, dass dies einer unserer blinden Flecken ist.
Während ich es lese, macht Ihr Team eine Schätzung, die es für „unrealistisch“ hält (eine Fantasie? Unehrlichkeit?) und verdoppelt sie dann, um sie „realistischer“ zu machen (weniger fantasievoll? ehrlicher?). Warum nicht zunächst einmal bei realistischen Schätzungen bleiben? Wenn die Anforderungen nicht detailliert genug sind, um eine realistische Schätzung vorzunehmen, warum nicht darauf verzichten? Wenn die Arbeit Monate im Voraus von Leuten außerhalb des Scrum-Teams auf das Team übertragen wird, warum nicht das Scrum-Ding machen, bei dem Elemente während der Sprint-Planung vom Entwicklungsteam in einen Sprint gezogen werden?

Antworten (6)

Um diese Art von „Verhaltensänderungs“-Aktionen im Auge des Teams zu behalten, finde ich einen effektiven Weg, sie neben die Kanban-Tafel zu hängen, die groß genug ist, dass sie aus der Ferne gelesen werden können. Und erinnern Sie das Team von Zeit zu Zeit an diese Aktionen, wenn Sie glauben, dass sie verfallen sein könnten.

Ich mag die Idee, sie auf oder neben dem Board sichtbar zu machen. Um sicherzustellen, dass sie lesbar sind, würde ich wahrscheinlich versuchen, für jede Richtlinie Abkürzungen (Zusammenfassungen mit 1 oder 2 Wörtern für jede Richtlinie) zu finden. Und anstatt diese Richtlinien ständig durchzugehen (eine sehr langweilige Methode, um sicherzustellen, dass sie in Erinnerung bleiben), ist es wahrscheinlich ein besserer Ansatz, sich auf das zu konzentrieren, was meiner Beobachtung nach fehlt.

Es gibt auch den Begriff „ integrierte Qualität “. Das bedeutet, dass die von Ihnen beschriebenen Prozessrichtlinien so nah wie möglich dort sein sollten, wo sie benötigt werden. Legen Sie zum Beispiel WIP-Limits auf Ihrem Board fest, wie in Kanban. Oder Spalten entsprechend nennen, oder eine kurze Notiz mit kommenden Regeln darauf schreiben.

Das sind meine zwei Vorschläge:

  • Von einem Retro abgeleitete Aktionselemente müssen ihren Weg in ein Dokument finden
  • Sie können dem aktuellen Sprint eine Aufgabe hinzufügen, um Probleme zu lösen, die in der Retro aufgeworfen wurden, und sie sollte nur dann als abgeschlossen markiert werden, wenn Sie einen echten Weg gefunden haben, das Problem für immer zu beseitigen

Anscheinend glauben Sie nicht, dass es funktionieren würde, dies in Dokumente zu integrieren, aber ich glaube, Sie müssen Ihr Team davon überzeugen, dass Dokumente Vereinbarungen darstellen. Sie sollen nicht statisch sein, es wird erwartet, dass sie sich ändern, um auf die Anforderungen Ihres Projekts zu reagieren.

Ich bin nicht unbedingt dagegen, sie in ein Dokument aufzunehmen, ich mache mir nur Sorgen, dass das Team diese Dinge vergisst, auf die sie sich geeinigt haben, weil sie nicht „greifbar“ oder sichtbar genug sind. Wie stellen Sie sicher, dass das Team ihnen folgt?
Ich mag die Idee, eine Aufgabe an der Tafel zu erstellen, wenn es keine klare Lösung gibt. Ich konnte sehen, wie es leicht in eine interne User Story übersetzt werden könnte.
Ich denke, Ihr Team muss sich nur daran gewöhnen, zu den Dokumenten zu gehen. Stellen Sie sicher, dass sie ihren Wert verstehen und dass sie strukturiert und nicht zu lang sind. Sie können zum Beispiel ein Dokument für Arbeitsweisen haben, ein anderes für Diskussionsrichtlinien, vielleicht noch eins für Notfälle usw.

Wenn es sich um eine Verhaltensänderung handelt, sollte es meiner Erfahrung nach nicht länger als ein paar Sprints/Wochen dauern, bis das neue Verhalten zur Gewohnheit wird. Mein Vorschlag ist, sie wie jede andere Aktion zu behandeln, sie auf Ihr Taskboard zu setzen und regelmäßig nachzuverfolgen.

Wenn sie nach einiger Zeit immer noch viel Aufmerksamkeit brauchen, dann gibt es ein tieferes Problem. Die wiederkehrende Aktion könnte ein nachträglicher Geruch sein , der Aufmerksamkeit erfordert.

Macht das Sinn?

Ja! Ich mag auch die Metapher des „rückblickenden Geruchs“. Ich werde es versuchen.

Der beste Weg, solche Änderungen umzusetzen, ist direkt im System selbst.

Zu Punkt 1: Sie könnten die DoD für die Spalte vor dem Bau so ändern, dass sie "Überprüfungskriterien vorbereiten" enthält, oder sie sogar zu einer zusätzlichen Spalte vor dem Bau machen.

2: (Abgesehen von der Tatsache, dass es sicher bessere Alternativen zum Schätzen gibt) würde ich das System ändern, das die Schätzung verwendet. Wenn Sie es beispielsweise mit 1000 multiplizieren, um einen Preis zu erhalten, beginnen Sie stattdessen mit der Multiplikation mit 2000.

3: Auch dies ist entweder eine Ergänzung zum DoD der Scoping-Spalte oder eine zusätzliche Spalte davor oder danach.

Ein „Shu“-Vorschlag: Machen Sie diese Ausgaben in einem speziellen Retro Issues Backlog sichtbar. Wenn das Problem erneut auftritt, markieren Sie es mit einem roten Punkt, oder wenn es weiterhin besteht, mit einem gelben Punkt. Wenn ein neuer Punkt auftaucht, bitten Sie das Team, Gründe oder Bedingungen zu sammeln, die neue Punkte zulassen. Fragen Sie andere Teams, ob sie die gleiche Situation haben oder wie sie damit umgehen.

Wie sollten wir wiederkehrende oder immaterielle retrospektive Aktionspunkte implementieren und verfolgen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v