Cluster-Retrospektive

Die Cluster-Retrospektive bietet dem Cluster-Scrum-Master (CSM) die Gelegenheit, die Arbeitsweisen des Clusters, vertreten durch den Cluster-Product-Owner und die Team-System-Engineer-Gruppe (TSEG), zu überprüfen, sowie Verbesserungen der Arbeitsweise für den kommende Cycle zu identifizieren und zu einzuplanen. Die Cluster-Retrospektive findet zwischen dem Cluster-Review und dem nächsten Cluster-Planning statt und basiert auf den Ergebnissen der Team-Retrospektiven der Teams, die meist von der Team-Scrum-Master-Gruppe aufbereitet wurden. Für einen vierteljährliche Cycle wird hierfür eine Obergrenze von vier Stunden angesetzt. Bei kürzeren Cycles ist das Meeting in der Regel kürzer. Der CSM sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Der CSM sorgt dafür, dass das Meeting konstruktiv und produktiv ist und lehrt alle, den Zeitrahmen einzuhalten (Time-box). Aufgrund seiner Verantwortung für den P4-Prozess nimmt der CSM als gleichberechtigtes Mitglied an der Cluster-Retrospektive teil. Sie wird durchgeführt, um …

  • zu überprüfen wie der vergangene Cycle in Bezug auf die beteiligten Teams, Beziehungen, Prozesse, Infrastruktur und Werkzeuge verlief;
  • die wichtigsten und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Clusters zu erstellen.

Die Team-Scrum-Master-Gruppe arbeitet daran, die Entwicklungsprozesse und -praktiken des Clusters zu verbessern, damit die Teams des Clusters im  kommenden Cycle effektiver und befriedigender arbeiten zu können. Vor jeder Cluster-Retrospektive erarbeitet die Team-Scrum-Master-Gruppe Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der Definition-of-Done, sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen. Zum Ende der Cluster-Retrospektive sollte die TSMG Verbesserungen für den kommende Cycle identifiziert haben.

Die Team-Scrum-Master-Gruppe überprüft in der Cluster-Retrospektive ebenfalls die Arbeitsflüsse (Worksflows) zwischen den Teams (z.B. durch Value-Stream-Mapping) und passt die Verantwortungsbereiche der Teams und ggf. auch die Team-Strukturen innerhalb des Clusters an.

Die Team-Scrum-Master nehmen die Verbesserungsvorschläge und -maßnahmen mit in ihre Teams.

Ablauf der Cluster-Retrospektive

Meist bringen die Team-Scrum-Master Probleme, Behinderungen (Impediments) und Verbesserungsideen (Improvements) aus ihren Teams mit in die TSMG, die sie in den Team-Retrospektiven der Teams gesammelt haben. Diese werden im Cluster-Improvement-Backlog gesammelt und priorisiert. In der Arbeitszeit der TSMG werden die am höchsten priorisierten Improvements während des laufenden Cycles analysiert und bearbeitet. In der Cluster-Retrospektive werden Änderungen dann gemeinsam beschlossen und umgesetzt.

Für die Ermittlung von weiteren Problemen, Behinderungen und Verbesserungsideen auf Cluster-Ebene nutzt die TSMG die gleichen methodischen Ansätze und Fragestellungen, wie auf Team-Ebene, z.B.

  • Glad, Sad, Mad
  • Keep, Change, Puzzled
  • Good, Problems, Questions
  • Start, Stop, Keep, More, Less

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

.

Organisations-Retrospektive

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Cluster-Review

Am Ende jedes Cycles wird ein Cluster-Review abgehalten, in dem die Team-System-Engineer-Gruppe (TSEG) mit dem Cluster-Product-Owner (CPO), den Stakeholdern die Ergebnisse vorstellen. Dabei bekommen sie Feedback von den Stakeholdern zu den Ergebnissen, damit der CPO bei Bedarf das Cluster-Backlog anzupasst. Zusammen mit eventuellen Änderungen am Cluster-Backlog, die während des Cycles eingeflossen sind (z.B. in den Cluster-Backlog-Refinements), bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert der „Cluster-Produkte“ steigernden Einträgen. Beim Cluster-Review handelt es sich um ein informelles Meeting, keinen Statusreport im klassischen Sinn. Die Vorführung der Ergebnisse ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht. Am Ende des Cluster-Reviews kann der Cluster-Product-Owner ein Update zu Kosten und geplanten Terminen bzw. Meilensteinen geben.

Für einen zwölfwöchigen Cycle wird für dieses Meeting eine Obergrenze von vier Stunden als Zeitrahmen angesetzt. Für kürzere Cycles wird ein entsprechender kürzerer Zeitrahmen veranschlagt. Der Cluster-Scrum-Master (CSM) stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der CSM bringt allen Beteiligten bei, das Event innerhalb des vorgegebenen Zeitrahmens durchzuführen.

Das Cluster-Review beinhaltet die folgenden Elemente:

Das Ergebnis des Cluster-Reviews ist ein überarbeitetes Cluster-Backlog, das dem gemeinsamen Wissenstand der Teilnehmer entspricht und durch das die TSEG im  nächsten Cycle, an den Cluster-Backlog-Einträgen mit dem höchsten Wert arbeiten kann. Das Cluster-Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Review

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Retrospective

.

Portfolio-Review

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Cluster-Planning

Cluster-Planning in Cycles

Jeder Cycle beginnt mit einem Cluster-Planning-Event. In diesem präsentiert der Cluster-Product-Owner der Team-System-Engineer-Gruppe (TSEG) den aktuellen Stand des Cluster-Backlogs. Neue Einträge oder Änderungen, die der Team-System-Engineer-Gruppe seit dem letzten Cluster-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Cluster-Product-Owner innerhalb des Cluster-Backlogs priorisiert.

Die Team-System-Engineer-Gruppe ermittelt die Kapazität für den nächste Cycle durch einen Blick auf die bisherige Arbeitsgeschwindigkeit des Clusters (Cluster-Velocity) und durch einen Blick auf die Kapazität der Teams im nächsten Cycle.

Die Team-System-Engineer-Gruppe zieht die Anzahl von Cluster-Backlog-Items (CBI), die der Einschätzung des TSEG über die Kapazität im nächsten Cycle entspricht, in das Cycle-Backlog des Clusters (Pull). Danach verfeinern die Team-Product-Owner mit den TSEG die CBIs in Team-Backlog-Items, die zur Fertigstellung des CBIs nötig sind.

Danach startet die TSEG den Cycle durch ziehen der ersten Aufgaben von „open“ nach „in progress“.

Kontinuierliches Cluster-Planning

Alternativ zum Planungsrhythmus in Cycles, kann die Planung der Arbeiten für den Cluster auch kontinuierlich erfolgen. Hierfür werden die Cluster-Backlog-Refinements genutzt, wobei ein Cluster-Backlog-Items direkt nach der Analyse und Schätzung, in Bearbeitung gehen kann.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

.

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Cluster-Improvement-Backlog

Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf allen drei Ebenen des P4-Frameworks (Team, Cluster, Organisation).

Jedes Team, das mehr Verbesserungen identifiziert, als momentan umsetzbar sind, legt diese Verbesserungen in ihrem Team-Improvement-Backlog ab, das der Team-Scrum-Master mit dem Team priorisiert.

Die Summe der Verbesserungen eines Clusters befindet sich im Cluster-Improvement-Backlog, das der Cluster-Scrum-Master mit der Team-Scrum-Master-Gruppe priorisiert. Das Cluster-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Teams gespeist.

Die Summe der Verbesserungen einer Organisation befindet sich im Organisation-Improvement-Backlog, das der Organisation-Scrum-Master mit der Cluster-Scrum-Master-Gruppe priorisiert. Das Organisations-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Cluster gespeist.

.


Passende und weiterführende Artikel:\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Team-Improvement-Backlog

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Organisations-Improvement-Backlog

Cluster-DoD

Die Teams des Clusters, die Team-System-Engineer-Gruppe, die Team-Product-Owner-Gruppe und die Stakeholder müssen sich darauf einigen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als erledigt („Done“) bezeichnet wird. Obwohl sich dies erheblich von Cluster zu Cluster unterscheiden kann, müssen alle ein gemeinsames Verständnis davon haben, wann Arbeit erledigt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition-of-Done des jeweiligen Clusters.

Die Cluster-DoD ist das Qualitätsversprechen des Clusters

Die DoD leitet die Team-System-Engineer-Gruppe auch bei der Entscheidung, wie viele Cluster-Backlog-Einträge es während des Cluster-Plannings in das Cycle-Backlog ziehen kann. Der Zweck jedes Zyklus ist es, inspizierbare Ergebnisse, verwendbares Wissen oder potenziell auslieferbare Funktionalität innerhalb eines System-Inkrements zu liefern, die der aktuellen Definition-of-Done entsprechen. Cluster liefern in jedem Zyklus ein Inkrement an Ergebnissen, Wissen und/oder Systemfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Cluster-Product-Owner sich jederzeit dazu entscheiden kann, es zu freizugeben.

Wenn die Definition-of-Done für ein Produkt Teil von Konventionen, Standards oder Richtlinien der Organisation ist, müssen alle Cluster diese als Minimalziel befolgen. Wenn „Done“ für ein Produkt nicht Teil der Konvention der Organisation ist, muss der Cluster (d.h. die TSEG) eine für das Produkt geeignete Definition-of-Done formulieren. Wenn es mehrere Cluster gibt, die am selben System arbeiten, müssen alle Cluster gemeinsam eine Definition-of-Done erstellen. Jedes System-Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet, um sicherzustellen, dass alle Inkremente gemeinsam funktionieren. Von reiferen Clustern wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet erweitern, um strengere Kriterien für eine höhere Qualität sicherzustellen. Neue Einträge in der Definition-of-Done können dazu führen, dass noch zu erledigende Arbeit in früheren „Done“ System-Inkrementen aufgedeckt wird (auch als „technische Schulden“ bekannt).

Jedes einzelne Ergebnis, Produkt oder System sollte eine Definition-of-Done haben, die den Standard für jegliche daran durchgeführte Arbeit darstellt.

Die Definition-of-Done entspricht daher in ihrem Wesen, den Prozessbeschreibungen und „Standard-Operation-Procedures“ einer klassischen Organisation, allerdings in einer starkt kondensierten Form.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-Improvement-Backlog

.

Organisations-DoD