Team-Product-Owner

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

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.

Module-Owner

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 und Application-Owner

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-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

.

Portfolio-Owner

Working-Team

.

Team-Product-Owner-Gruppe

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Cluster-System-Engineer-Gruppe (CSEG)

Die Cluster-System-Engineer-Gruppe (CSEG) besteht aus den Cluster-System-Engineers aller Cluster der Organisation. Sie entspricht auf der Organisationsebene der Rolle des Working-Teams auf Team-Ebene.

Die Cluster-System-Engineer-Gruppe hat mit dem Portfolio Architect auf der Organisations- bzw. der Portfolio-Ebene die Verantwortung für die Technologie- und Architekturseite des Produktentstehungsprozesses.

Weiterlesen

Kadenz (Cadence) eines Jahres

Die Kadenz (englisch Cadence) ist eine zentral festgelegte Event-Planung für die Organisation. Sie ermöglicht es, ähnlich einem Stundenplan an einer Schule oder Universität, dass …

  •  alle Rollen innerhalb der Organisation an den für sie vorgesehenen Events teilnehmen können. (Keine überlappenden Einladungen)
  • alle privaten Events der Teams und Gruppen gleichzeitig stattfinden, um möglichst viel freie Arbeitszeit innerhalb der Teams und Gruppen zu ermöglichen

Die Kadenz eines Jahres besteht im P4-Framework aus vier sogenannten Cycles, die jeweils ein Vierteljahr betragen. An Übergängen zwischen den Cycles finden verschiedene Organisations- und Cluster-Events statt, ähnlich dem Iterationswechsel in Scrum. Es ist empfehlenswert, den Cycle-Wechsel nicht auf kalendarische Viereljahresgrenzen zu legen, damit ein Wechsel z.B. nicht mit dem Jahreswechsel und die davor liegenden Weihnachtszeit kollidiert.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Team-System-Engineer (TSE)

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-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-Product-Owner

Team-Scrum-Master

.

Cluster-System-Engineer

.

Portfolio-Architekt

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-DoD (Definition-of-Done)

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

Die DoD ist das Qualitätsversprechen des Teams

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

Wenn die Definition-of-Done für ein Team Teil von Konventionen, Standards oder Richtlinien des Clusters oder der Organisation ist, müssen alle Teams diese Cluster-DoD als Minimalziel befolgen. Wenn „Done“ für ein Team nicht Teil der Konvention des Clusters oder der Organisation ist, muss das Team eine für die Team-Ergebnisse geeignete Definition-of-Done formulieren. Wenn es mehrere Teams gibt, die am selben System arbeiten, müssen alle Teams 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 Teams wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet anpassen, 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.

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
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-Improvement-Backlog

.

Cluster-DoD

.

Organisations-DoD

Integrated System Sample & Increments

System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie (je nach Grad der Regulierung) durch Nutzer- oder sogar Markttests verifiziert werden.

System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilprodukten der verschiedenen Teams eines Clusters.

Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).

Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut

Prototype Name Description
B Base Prototype for design space exploration
C Critical Function Prototype Need finding; feasibility; fail early
D Dark Horse Prototype The alternative; thinking out of the box
E Emergent Prototype Combining several functions and ideas; iterative and incremental
F Functional Prototype Fully functional, but differs in (e.g. form-factor)
G Gap Closing Prototype Specific to close Knowledge Gaps or prove Hypotheses
H Hindmost Prototype Closest to series production

All Prototype can appear as iterating Prototypes, like G1, G2, G3.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD