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

Das Team und die Team-Ebene

Das Team ist das Basiselement einer agil arbeitenden Organisation und bildet die Heimat von Mitarbeitern.

Die meisten Arbeiten finden in stabilen und langlebigen Teams statt. Durch die Stabilität bzw. „Langlebigkeit“ sind die Teams bei Problemen auch dann verfügbar, wenn momentan gerade nicht an einer Überarbeitung der Applikation/Systemvariante gearbeitet wird (also, wenn klassisch aufgestellte Projekt-Teams nicht mehr bestehen).

P4 übernimmt die Grundstruktur eines Teams aus Scrum. Es besteht aus Team-Product-Owner, Team-Scrum-Master und dem Working-Team, die zusammen für die Stakeholder arbeiten. Durch das Prinzip der Gewaltenteilung ergeben sich klar umrissene Verantwortungsbereiche, die sich im Team ergänzen.

Der Team-Product-Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, der aus der Arbeit des Working-Teams entsteht. Wie dies geschieht, kann je nach Organisation, und Working-Team, sowie den darin arbeitenden Experten, stark variieren. Der Team Product-Owner ist die einzige Person, die für das Management des Team-Backlogs verantwortlich ist.

Das Working-Team  besteht aus drei bis neun Mitgliedern und dem System-Engineer, die in jeder Iteration fertige und inspizierbare Ergebnisse erarbeiten und am Ende der Iteration im Team-Review vorstellen, idealerweise ein potenziell auslieferbares System oder Teilsystem.

Der Team-Scrum-Master ist ein „Servant-Manager“ und ist dafür verantwortlich, die Team-Arbeit entsprechend den Scrum- und P4-Regeln zu fördern und zu unterstützen, indem sie allen Beteiligten helfen, die Werte und  Praktiken zu verstehen.

Weiterlesen