Interessante Frage. Nachdem ich hier aber nicht "(nur für Mitglieder sichtbar)" sehe, möchte ich mich dazu nicht konkret äussern.

Zitat von LaberKachelSülz im Beitrag #2

---

möchte ich mich dazu nicht konkret äussern.

---

Zitat von Nina im Beitrag #4

---

Wobei es sich bei der Retro ja eher um ein Feedback hinsichtlich der Methode handelt.

---

Und? Wie ist deine Retro gelaufen?

ach Schade, das tut mir leid für dich, Nina.

Macht es in so einem konkreten Fall wie jetzt bei dir Sinn, die Retro mit voller Besetzung zu einem späteren Zeitpunkt nachzuholen?

So was muss eben auch mal sein. Ich denke, solche "Retros" (auch wenn es dann keine Retrospektive im eigentlichen Sinn ist) sind auch mal wichtig. War dann eben eine Urlaubsretro :)

Zitat von Tachon32 im Beitrag #3

---

Zitat von LaberKachelSülz im Beitrag #2

---

möchte ich mich dazu nicht konkret äussern.

---

hehe, dann poste doch nix :-))))

---

Hallo erstmal! Ich bin neu hier und habe mich hier mal vorgestellt.

Spannendes Thema. Stets eine "gute" Retrospektive zu haben, ist für mich nicht die richtige Frage. Ich schaue eher darauf, ob sich ein Team im langfristigen Trend in dem wie  es (zusammen-)arbeitet verbessert. Das beinhaltet soziale, organisatorische und technische Aspekte. Das kritische Element ist da für mich zwischen den Retrospektiven: Wird an den Punkten, die erkannt werden, auch tatsächlich gearbeitet? Gibt es Follow-Ups in der folgenden Retrospektive? Gibt es eine "Retrospektive der Retrospektive" oder anders: Wird vom Team selbst überprüft, ob und wie gut kontinuierliche Verbesserung stattfindet?

Damit ein Team das macht, finde ich es essentiell, dass das Team versteht:

- Zweck der Retrospektive deutlich machen: Es geht vorwiegend um den Prozess, weniger um das Produkt. Die Zusammenarbeit und technische Aspekte (Tools, Umgebungen, Automatisierung). Möchte das Team über das Produkt sprechen, dann ggf. mehr Zeit für das Backlog Grooming schaffen.
- Scrum (als Beispiel) ist ein empirischer Prozess. Bedeutet: Es wird anhand der vorhandenen Daten und Fakten geplant und gehandelt.
- Bewusstsein darüber, dass dem Team der Prozess (innerhalb des Rahmens, z.B. Scrum) "gehört" und auch verantwortet (und nicht mehr andere Personen)
- Einen klar abgesteckten Rahmen, in dem kontinuierliche Verbesserung geschehen darf: Wenn ich nicht weiß, was ich anpassen darf (und was nicht), werde ich das auch eher nicht tun (oder laufe Gefahr, in Schwierigkeiten zu kommen). Auch fehlt der Anhaltspunkt, wo Verbesserungen ansetzen können und sollten. Der Rahmen von Scrum ist beispielsweise gesetzt und wird nicht angepasst. Auch müssen evtl. andere unternehmensspezifische Dinge beachtet werden (und die muss das Team kennen)

Natürlich ist in Retrospektiven auch Abwechslung ein Aspekt. Aber wenn Retrospektiven "einschlafen", liegt das für mich meist daran, dass diese drei Punkte nicht klar sind und das Team eher ins Konsumieren gerät, statt in die Verbesserungsarbeit. Abwechslung ist für mich dahingehend wichtig, dass das Team Zusammenhänge von unterschiedlichen Seiten beleuchtet oder Scheuklappen ablegt.

Was macht eine "gute" Retrospektive aus?

- Klare Timebox setzen und einhalten
- Mit Leuten reden statt über sie
- Als Scrum Master / Coach das Team zu mindestens einem kleinen Action-Item bringen (manchmal sogar zu bremsen)
- Follow-Ups für die Action-Items und ggf. weiter planen

Wie werden Action-Items auch umgesetzt?

- Für das Team (wirklich) Action-Items werden wahrscheinlicher umgesetzt
- Auf kleine Action-Items achten
- Action-Items im Sprint sichtbar machen (z.B. als Poster an der Tür oder an der Kaffee-Maschine)
- Ggf. Action-Items im Sprint Planning schätzen und mit einplanen

Was passiert, wenn das Team bei seiner kontinuierlichen Verbesserung an die Grenzen kommt? Das muss erstmal passieren :-) Geht aber auch ganz schnell, wenn im Unternehmen Scrum ein Fremdkörper ist. Hier muss dann der Scrum Master / Coach dem Team Sicherheit vermitteln und versuchen, die Brücke zu denjenigen zu schlagen, die den Rahmen anpassen können. Nur Vorsicht bei Anpassungen am Scrum-Rahmen: Das wird immer schnell mal vorgeschlagen, wenn Sinn und Zweck bestimmter Scrum-Elemente nicht verstanden werden und gefühlt "im Weg stehen".

Unterm Strich muss da aber auch wieder jedes Team sein eigenes Rezept finden :-)