Ein Cluster innerhalb Produktentwicklungsorganisation wird von einer Gruppe von Managern gelenkt. Es besteht mindestens aus folgenden Rollen:
Weitere Managementrollen ergänzen den Management-Kreis je nach Art und Ausrichtung des Clusters.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning
. |
Team-Product-Owner
. . |
Team-Product-Owner-Gruppe
. |
.
Nutzbares-Wissen & System-Inkrement . |
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 …
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.
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.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Retrospektive
. . |
Cluster-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |
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-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |
Als Refinement (Verfeinerung) des Cluster-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Cluster-Backlog bestimmt werden.
Der Cluster-System-Engineer hat mit der Team-System-Engineer-Gruppe auf der Cluster/System-Ebene die Verantwortung für die Technologie und Architektur innerhalb des Produktentstehungsprozesses.
Der Cluster-Product-Owner hat mit der Team-Product-Owner-Gruppe auf der Cluster- und System-Ebene die Verantwortung für die Markt- und Geschäftsseite innerhalb des Produktentwicklungsprozesses. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
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“.
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-Product-Owner | Team-Product-Owner-Gruppe | Cluster-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-Product-Owner | Team-Product-Owner-Gruppe | Team-Improvement-Backlog
. Nutzbares-Wissen & System-Inkrement . |
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 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-Product-Owner | Team-Product-Owner-Gruppe | Team-DoD
. Nutzbares-Wissen & System-Inkrement . |
Jeder Cluster besteht aus mehreren Teams und unterteilt die Organisation in sinnvolle Wertströme. Er organisiert die verschiedenen Systeme, Applikationen (Produkte) und Märkte. Hierfür besitzt er ein Cluster-Backlog mit Systemversionen bestehend aus Features und Modulen als Elemente, ein Cluster-Kanban-Board und die Cluster-DoD.