Die Produktentwicklungsorganisation wird von einer Gruppe aus Managern gelenkt. Es besteht mindestens aus folgenden Rollen:
Weitere Managementrollen ergänzen den Management-Kreis je nach Art und Ausrichtung der Organisation. Häufig laufen die Fäden bei einem CEO zusammen.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Portfolio-Planung | Team-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Portfolio-Backlog |
Die Organisations-Retrospektive bietet dem Organisations-Scrum-Master (OSM) die Gelegenheit, die Arbeitsweisen der Organisation, vertreten durch den Portfolio-Owner (PFO) und die Cluster-System-Engineer-Gruppe (CSEG), zu überprüfen, sowie Verbesserungen der Arbeitsweise für den kommende Cycle zu identifizieren und zu einzuplanen. Die Organisations-Retrospektive findet zwischen dem Portfolio-Review und dem nächsten Portfolio-Planning statt und basiert auf den Ergebnissen der Cluster-Retrospektiven, die meist von der Cluster-Scrum-Master-Gruppe aufbereitet wurden. Für einen vierteljährliche Cycle wird hierfür eine Obergrenze von vier Stunden angesetzt. Der Organisations-Scrum-Master (OSM) sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Der OSM 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 OSM als gleichberechtigtes Mitglied an der Organisations-Retrospektive teil. Sie wird durchgeführt, um …
Die Cluster-Scrum-Master-Gruppe arbeitet daran, die Entwicklungsprozesse und -praktiken der Organisation zu verbessern, damit die Cluster im kommenden Cycle effektiver und befriedigender arbeiten zu können. Vor jeder Organisations-Retrospektive erarbeitet die Cluster-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 Organisations-Retrospektive sollte die CSMG Verbesserungen für den kommende Cycle identifiziert haben.
Die CSMG überprüft in der Organisations-Retrospektive ebenfalls die Arbeitsflüsse (Workflows) zwischen den Clustern (z.B. durch Value-Stream-Mapping) und passt die Verantwortungsbereiche der Cluster und ggf. auch die Cluster-Strukturen innerhalb des Organisation an.
Die Cluster-Scrum-Master nehmen die Verbesserungsvorschläge und -maßnahmen mit in ihre Cluster.
Meist bringen die Cluster-Scrum-Master Probleme, Behinderungen (Impediments) und Verbesserungsideen (Improvements) aus ihren Clustern mit in die CSMG, die sie in den Cluster-Retrospektiven der Cluster gesammelt haben. Diese werden im Organisations-Improvement-Backlog gesammelt und priorisiert. In der Arbeitszeit der CSMG werden die am höchsten priorisierten Improvements während des laufenden Cycles analysiert und bearbeitet. In der Organisations-Retrospektive werden Änderungen dann gemeinsam beschlossen und umgesetzt.
Für die Ermittlung von weiteren Problemen, Behinderungen und Verbesserungsideen auf Organisations-Ebene, nutzt die CSMG 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
. . |
Portfolio-Owner | Cluster-Product-Owner-Gruppe | Portfolio-Backlog |
Am Ende jedes Cycles wird ein Portfolio-Review abgehalten, in dem die Cluster-System-Engineer-Gruppe (CSEG) mit dem Portfolio-Owner (PFO), den Stakeholdern die Ergebnisse vorstellen. Dabei bekommen sie Feedback von den Stakeholdern zu den Ergebnissen, damit der Portfolio-Owner bei Bedarf das Portfolio-Backlog anzupasst. Zusammen mit eventuellen Änderungen am Portfolio-Backlog, die während des Cycles eingeflossen sind (z.B. in den Portfolio-Backlog-Refinements), bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Portfolios steigernden Einträgen. Beim Portfolio-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 Basis für die Zusammenarbeit gedacht. Am Ende des Portfolio-Reviews kann der Portfolio-Owner ein Update zu Budgets und wichtigen 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 Organisations-Scrum-Master (OSM) stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der OSM bringt allen Beteiligten bei, das Event innerhalb des vorgegebenen Zeitrahmens durchzuführen.
Das Portfolio-Review beinhaltet die folgenden Elemente:
Das Ergebnis des Portfolio-Reviews ist ein überarbeitetes Portfolio-Backlog, das dem gemeinsamen Wissenstand der Teilnehmer entspricht und durch das die CSEG im nächsten Cycle, an den Portfolio-Backlog-Einträgen mit dem höchsten Wert arbeiten kann. Das Portfolio-Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Review
. . |
Portfolio-Owner | Cluster-Product-Owner-Gruppe | Portfolio-Backlog |
Die Planung auf Portfolio-Ebene ist im P4-Framework ein semi-kontinuierlicher Prozess, genauso wie z.B. die Budgetplanung, die eng mit der Portfolioplanung verknüpft ist. Der Planungsprozess besteht aus der Vorbereitung durch das Portfolio-Refinement und das Portfolio-Planungs-Event. Der Planungsprozess findet auf der Ebene der Portfolio-Backlog-Elemente statt. Diese sind:
Zeitlich wird häufig in folgenden Abschnitten geplant, nach dem Prinzip „je näher, desto feiner“:
Änderungen an der Portfolio-Planung fließen also gut vorbereitet und zu bestimmten Zeiten in die Organisation. Bei Darstellung auf einem Portfolio-Kanban-Board wird auf diese Weise die gesamte Arbeit der Organisation transparent.
Jeder Cycle für die gesamte Organisation beginnt mit einer Portfolio-Planung. In dieser präsentiert der Portfolio-Owner (PFO) der Cluster-System-Engineer-Gruppe (CSEG) den aktuellen Stand des Portfolio-Backlogs. Neue Einträge oder Änderungen, die der Cluster-System-Engineer-Gruppe seit dem letzten Portfolio-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Portfolio-Owner innerhalb des Portfolio-Backlogs priorisiert.
Die Cluster-System-Engineer-Gruppe ermittelt die Kapazität für den nächsten Cycle durch einen Blick auf die bisherige Arbeitsgeschwindigkeit der Organisation (Organisations-Velocity) und durch einen Blick auf die Kapazität der Cluster im nächsten Cycle.
Die Cluster-System-Engineer-Gruppe zieht die Anzahl von Portfolio-Backlog-Items (PFBI), die der Einschätzung des CSEG über die Kapazität im nächsten Cycle entspricht, in das Cycle-Backlog der Organisation (Pull). Danach verfeinern die Cluster-Product-Owner mit der CSEG die PFBIs in Cluster-Backlog-Items, die zur Fertigstellung des PFBIs nötig sind.
Danach startet die CSEG den Cycle durch ziehen der ersten Aufgaben von „open“ nach „in progress“.
Alternativ kann die gesamte Portfolio-Planung auch kontinuierlich durch Nutzung eines Kanban-Systems erfolgen. Dabei entfällt der Cycle als Timebox und die Velocity als Maß für die Arbeitsgeschwindigkeit. Die kontinuierliche Portfolio-Planung erfolgt dann durch regelmäßige Treffen von CSEG und Portfolio-Owner (meist einmal pro Iteration). Die Aktivitäten „Vorstellen“, „Schätzen“ und Priorisieren von Backlog-Elementen passiert dann auf Basis einzelner Elemente. Das Ziehen (Pull) von Backlog-Elementen erfolgt auf Basis von sogn. Work-in-Progress-Limits (WiP-Limit).
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning
. . |
Portfolio-Owner | Cluster-Product-Owner-Gruppe | Portfolio-Backlog |
Als Refinement (Verfeinerung) des Portfolio-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, Backlog-Einträge zerteilt werden oder die Reihenfolge der Einträge im Portfolio-Backlog geändert werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Porfolio-Owner und die Cluster-System-Engineer-Gruppe (CSEG) gemeinsam die Portfolio-Backlog-Einträge detaillieren. Bei der Verfeinerung des Portfolio-Backlogs werden die Einträge begutachtet und revidiert. Der Portfolio-Owner kann jedoch jederzeit die Einträge im Portfolio-Backlog aktualisieren oder aktualisieren lassen.
Das Portfolio-Backlog-Refinement dient hauptsächlich der Vorbereitung der nächsten Portfolio-Planung. Dabei stellt der Portfolio-Owner der Cluster-System-Engineer-Gruppe (CSEG) neue Backlog-Einträge vor und lässt diese schätzen. Dies ist eine Voraussetzung für das „Pull“ der CSEG und wird oft auch als Definition-of-Ready bezeichnet. Bei unklaren aber hoch priorisierten Backlog-Einträgen klärt die CSEG die System-Anforderungen, mögliche System-Konzepte und Fähigkeiten. Dies kann sie als Gruppe selbst erarbeiten oder es wird ein entsprechender Backlog-Eintrag als Auftrag für einen der Cluster erzeugt.
Schätzungen durch die gesamte Cluster-System-Engineer-Gruppe sind aus zwei Gründen wichtig:
Zur Schätzung des Aufwands bedient sich das Team der Methodik des Planning-Poker®.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Backlog-Refinement
. . |
Portfolio-Owner | Cluster-Product-Owner-Gruppe | Portfolio-Backlog |
Der Portfolio-Architekt hat mit der Cluster-System-Engineer-Gruppe auf der Portfolio- und Organisationsebene die Verantwortung für die Technologie- und Architekturseite des gesamten Produktentwicklungsprozesses.
Der Portfolio-Architekt bildet mit dem Portfolio-Owner und dem Organisation-Scrum-Master das Management der gesamten Organisation.
Der Portfolio-Owner ist der Product Owner der Organisation. Er hat zusammen mit der Cluster-Product-Owner-Gruppe (CPOG) auf der Portfolio- bzw. Organisationsebene die Gesamtverantwortung für die Markt- und Geschäftsseite des Produktentwicklungsprozesses. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
Die Organisation ist die oberste Ebene in P4 und organisiert das Portfolio. Hierfür besitzt die Organisation ein Portfolio-Backlog mit Applikationen als Elemente, ein Portfolio-Kanban-Board und die Organisations-DoD.
Dieses Event ermöglicht, dass mehrere Cluster miteinander kommunizieren, um Abhängigkeiten, Störungen, neue Erkenntnisse und Entscheidungen, etc. während der laufenden Arbeit untereinander abzustimmen. Die Cluster entscheiden selbst, wie häufig dies benötigt wird (z.B. täglich, wöchentlich).
Die Vertreter des Clusters können die Cluster-System-Engineers der Cluster sein. Es können aber auch andere technische Vertreter des Clusters dazu bestimmt werden.
Das Organisation-Sync findet (meist im Halbkreis) vor dem Portfolio-Kanban-Board der Organisation statt, da die Mitglieder im Organisations-Sync die Portfolio-Backlog-Items bewegen.
Die drei Fragen im Organisations-Sync lauten:
In ähnlicher Weise kann die Struktur des Organisations-Sync auch für den Austausch bestimmter Rollen oder Expertisen genutzt werden, z.B. ein Sync der Cluster-Scrum-Master, der Cluster-Product-Owner, der Tester, der Konstrukteure, Designer, etc. eines Clusters.
Durch die Kürze von maximal 15 Minuten ist das Organisations-Sync nur dazu geeignet, Probleme zu identifizieren, nicht aber diese zu diskutieren oder zu lösen. Für die Diskussion von Problemen können die benötigten Mitglieder die Zeit nach dem Organisations-Sync nutzen, während die nicht benötigten Mitglieder weiterarbeiten können.
Besucher, die das Organisations-Sync miterleben wollen, können mit Erlaubnis der Mitglieder teilnehmen. Dabei stehen die Besucher in der zweiten Reihe und hören nur zu, außer sie werden von einem aktiven Mitglied angesprochen. Besucher können sein:
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Sync
. . |
Portfolio-Owner | Cluster-Product-Owner-Group | Portfolio-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.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Portfolio-Planung | Portfolio-Owner | Cluster-Product-Owner-Gruppe | Team-Improvement-Backlog
. . |