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 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 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 …)
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 …)
Der Team-Product-Owner priorisiert das Team-Backlog und nimmt die Ergebnisse des Working-Teams ab. Im Team-Backlog können mehrere Produktentwicklungen oder Teile davon enthalten sein. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
Je nach Art und Verantwortungsbereich des Teams (Team-Flavor) sind die Ergebnisse bzw. „Produkte“ der Teams sehr unterschiedlich. Daher können die Team-Product-Owner in P4 verschiedene Bezeichnungen haben:
Service-Owner sind die fachlichen Leiter von Teams, die eine Expertise oder Kompetenz verantworten. Oft sind Mitglieder solcher Service-Teams zu speziell oder zu wenige, dass sie ständig in interdisziplinären Teams mitarbeiten könnten. Ein anderer Grund für ein Service-Team ist, das es eine spezielle Infrastruktur betreibt, z.B. ein Labor. Diese Teams sind häufig eine Art interner Dienstleiter innerhalb der Organisation (Service-Provider) und werden meist von anderen Teams aufgesucht oder zu ihnen eingeladen.
Der Service-Owner ist dafür verantwortlich, die Dienstleistungsaufträge seines Teams zu priorisieren. Im einfachsten Fall wendet er und sein Team ein Kanban-Board mit einem First-come-first-serve-Prinzip an (FIFO). Der Service-Owner kann aber auch das Dienstleistungsangebot seines Teams in Klassen einteilen, z.B. mittels unterschiedlichen Service-Level-Agreements zu unterschiedlichen Kosten.
Um einen optimalen Fluss der Systementwicklung zu erreichen, übernimmt der Service-Owner im einfachsten Fall die Prioritäten aus dem Portfolio-Backlog bzw. dem Cluster-Backlog. Zusätzlich stimmt er sich regelmäßig mit den anderen Team-Product-Ownern innerhalb der Team-Product-Owner-Gruppe (TPOG) ab.
Bei der Entwicklung komplexer Systeme wird es häufig Subsysteme oder Module geben, um die Komplexität beherrschbarer zu machen (Module kapseln Komplexität) oder um mittels eines Plattform- bzw. Baukastenkonzepts die Wiederverwendung von Modulen und Komponenten zu ermöglichen.
Ein Modul-Owner ist daher der fachliche Manager, der dafür sorgt, dass die passenden Module für die Applikations- und Systementwicklung zur Verfügung stehen. Andererseits ist er dafür verantwortlich, dass die Module wiederverwendbar sind. Dabei kommt es im besonderen Maße auf stabile Schnittstellen für ein Plattform- bzw. Baukastensystem an.
Feature-Owner sind die Team-Product-Owner von interdisziplinären Teams, die ein oder mehrere Funktionen (Features) einer Systemvarianten (=Applikationen) entwickeln und verantworten, sowie diese für Anwender zur Verfügung stellen. Der Feature-Owner ist dabei mit den anderen Feature-Ownern und dem Application-Owner für die Verbesserung des Kundennutzens des Produkts seines Application-Teams verantwortlich. Der Application-Owner stellt die direkte Schnittstelle zu den Anwendern der Applikation dar, um über Anforderungen und Änderungen der Applikation zu entscheiden.
Application-Owner sind die Team-Product-Owner der interdisziplinären Teams, die komplette Systemvarianten (=Applikationen) entwickeln und verantworten, sowie diese für Anwender zur Verfügung stellen. Der Application-Owner ist dabei für die Verbesserung des Kundennutzens des Produkts seines Application-Teams verantwortlich. Der Application-Owner stellt die direkte Schnittstelle zu den Anwendern der Applikation dar, um über Anforderungen und Änderungen der Applikation zu entscheiden. Je nach Organisation gibt es noch einen getrennten Liefer- und Betriebsbereich (Operations. Siehe p4-ops.com). Für manche Organisationen macht es Sinn, die Bereiche Entwicklung und Betrieb zusammenzulegen (DevOps), um Synergien durch direkteres und schnelleres Feedback zu erzielen.
Das Application-Team mit dem Application-Owner stellt den Auftraggeber der Modul- und Dienstleistungs-Teams dar. Applikation-Teams integrieren die von den Modul-Teams zur Verfügung gestellten Module mit Hilfe der Dienste der Service-Teams.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning | Team-System-Engineer
. . |
Working-Team
. |
Team-Backlog |
Der Team-System-Engineer vertritt die technische Expertise und Verantwortung seines Teams in der Team-System-Engineer-Gruppe des Clusters. Wenn das Team keine andere Regelung vereinbart, vertritt er das Team auch in den Cluster-Syncs (Scrum-of-Scrums). Hierfür sollte er oder sie ein möglichst breites Wissen über die Themen innerhalb seines Teams haben. Je nach Art und Verantwortungsbereich kann dies deutlich unterschiedlich sein.
Vertritt ein Service-Team eine bestimmte Expertise (z.B. EMV oder Akustik), ist der Team-System-Engineer meist der erfahrenste des Teams.
Innerhalb eines Modulteams kennt der Team-System-Engineer die Module seines Teams, ihre Stärken und Schwächen, sowie ihre Anwendungsbereiche.
Innerhalb eines Applikationsteams kennt der Team-System-Engineer die technischen Möglichkeiten zu Realisierung der von seinem Team verantworteten Applikationen am besten.
Innerhalb des Working-Teams hat der Team-System-Engineer die Rolle, technische Entscheidungen zu moderieren und zu treiben und, im Zweifelsfall, diese zu treffen. Er steht dabei nicht über dem Working-Team, sondern ist der „Erste unter Gleichen“ (Primus inter paris).
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning | Team-Product-Owner
. . |
Working-Team | Team-Backlog |
Practice-Leads sind fachliche Coaches oder Trainer innerhalb der Organisation, die sich um eine Expertise oder technische Disziplin kümmern. Sie führen eine Community-of-Practice, bilden deren Mitglieder aus und kümmern sich um die Weiterentwicklung des Themas und der Mitarbeiter innerhalb der Organisation.
Beim Übergang von klassischen Organisationen können die ehemaligen Linienvorgesetzten zu Practice-Leads werden.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Iteration
. |
Community of Practice
. . |
Practice Backlog |
Der Organisations-Scrum-Master hat mit der Cluster-Scrum-Master-Gruppe die Verantwortung für die Infrastruktur und Prozesse auf der Organisationsebene , also der gesamten Produktentwicklung.
Der Organisations-Scrum-Master bildet mit dem Portfolio-Architekt und dem Portfolio-Owner das Management der gesamten Organisation.
Der OSM sorgt dafür, dass die Teams innerhalb der Organisation über alle Cluster hinweg, optimal arbeiten können. Zusammen mit den Cluster Scrum Master (CSM) des Organisation sorgt er für einen optimalen Arbeitsfluss zwischen den Clustern, durch Lösen von Behinderungen und Problemen, die in der Zusammenarbeit der Cluster auftreten. Hierfür organisiert und moderiert er die Organisations-Retrospektive und leitet die Cluster-Scrum-Master-Gruppe, in der sich die CSMs austauschen um ein Optimum der Arbeitsbedingungen und des Arbeitsflusses innerhalb des Organisation anstreben.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Portfolio-Planung | Team-Scrum-Master
. . |
Cluster-Product-Owner-Gruppe | Portfolio-Backlog |
Der Cluster-Scrum-Master hat, zusammen mit der Team-Scrum-Master-Gruppe, des Clusters, die Verantwortung für die Infrastruktur und Prozesse.
Der TSM sorgt dafür, dass die Mitglieder seines Teams optimal arbeiten können. Er sorgt für einen optimalen Arbeitsfluss zwischen den Team-Mitgliedern, durch Entdecken von Verbesserungen und Lösen von Behinderungen und Problemen (dargestellt im Team-Improvement-Backlog), die in der Zusammenarbeit der Teams auftreten. Dies betrifft insbesondere solche, die durch das selbstorganisierte Working-Team nicht eigenständig gelöst werden können.
Hierfür organisiert und moderiert der TSM die Team-Retrospektive, in der sich die Team-Mitglieder austauschen um ein Optimum der Arbeitsbedingungen und des Arbeitsflusses innerhalb des Teams anstreben.
Der Team-Scrum-Master arbeitet mit anderen TSMs innerhalb des Clusters in der Team-Scrum-Master-Gruppe (TSMG) zusammen, um lokale Optimierungen innerhalb des Teams zu verhindern und Probleme bei der Zusammenarbeit mehrere Teams zu beheben.
Hier geht es zur allgemeinen Beschreibung der Scrum Master Rolle.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning | Team-Product-Owner
. . |
Working-Team | Team-Backlog |