Über P4-Dev: Pragmatische Paradigmen, Prinzipien und Praktiken

Das P4-Dev-Framework beschreibt eine neue Art der Organisationsstruktur für Unternehmen, die physische Produkte entwickeln. Zusammen mit seinem Schwester-Framework, dem P4-Ops für das operative Geschäft, beschreibt P4-Dev ein ganzheitliches Betriebssystem für die Produktentstehung in modernen Organisationen, die die Prinzipien von Lean und Agilität umsetzen.

Pragmatic Paradigms, Principals & Practices for Development

Das P4-Dev Framework (kurz P4) lehnt sich an das Scrum-Framework an und erweitert dies durch zusätzliche Ebenen, um damit Organisationen der Größe zwischen 30 und ca. 1000 Personen abbilden zu können (Skalierung). Auf diesen Ebenen werden zusätzliche Rollen, Artefakte und Events gemäß der Scrum-Prinzipien definiert. Teams können, neben Scrum, auch Kanban einsetzen.

P4 gliedert sich dabei in die Beschreibung von Rollen, Artefakten und Events:

  • Rollen: Die Beschreibung der Organisation in Form von Einzelrollen, Teams und Gruppen
  • Artefakte: Die Backlogs, Backlog-Elemente und Elementtypen, sowie die Ergebnisse und Produkte
  • Events: Zeiträume und Meetings, sowie deren Inhalte

Viele der beschriebenen pragmatischen Prinzipien und Praktiken sind aus anderen Systemen und Frameworks bekannt und werden im P4-Framework ganzheitlich integriert:

Warum noch ein agiles skalierendes Framework?

Obwohl es schon eine Reihe von Frameworks zur Skalierung von Agilität gibt, fehlen diesen einige Elemente, die insbesondere für die Entwicklung von physischen Produkten und komplexen Systemen nötig sind. Daher haben wir u.A. folgende weitere Elemente in das P4-Framework integriert:

Erweiterungen

Über die oben beschriebenen Praktiken hinaus, werden erprobte Elemente aus klassischen Methoden in den „P4-Werkzeugkasten“ integriert, wie z.B. Anforderungsmanagement, Testmanagement, Risikomanagement, sowie modellbasierte Entwicklung aus dem Systems-Engineering.

Da es sich bei P4 um ein Rahmenwerk handelt, können weitere nutzbringende und als nötig erachtete Praktiken integriert werden. Dabei ist aber unbedingt darauf zu achten, dass die P4-Prinzipien eingehalten werden (siehe P4-Prinzipien).

Was ist anders zur klassischen Matrixorganisation?

Eine klassische Matrixorganisation besteht i.d.R. aus den fachlichen Abteilungen (den Linien) und einer Projektorganisation, in der in vielen parallelen Projekten interdisziplinär zusammengearbeitet wird. Jeder Mitarbeiter arbeitet dabei meist in mehreren Projekten gleichzeitig. In großen Firmen gibt es manchmal noch eine dritte Dimension, die die Linienorganisation in eine international übergreifende und eine standortbezogene Linie aufteilt mit den entsprechenden zusätzlichen Vorgesetzten (manchmal als „dotted line“ bezeichnet).

In der heutigen Arbeitswelt ist dieses „Dienen mehrerer Herren“ häufig ein Problem, da zwar die meiste Arbeit in den Projekten geschieht, die Projektleiter aber häufig mit deutlich weniger Befugnissen ausgestattet sind und sich im Konfliktfall meist die Linienvorgesetzten durchsetzen. Dies wird verstärkt durch die Vielzahl der Linienvorgesetzten im interdisziplinären Projektteam, die meist durch unterschiedliche Ziele getrieben, in verschiedene Richtungen agieren.

In modernen agilen Frameworks, wie P4-Dev, werden die Machtverhältnisse der Matrix umgekehrt: Das über die Zeit stabile Team, in dem sich ein Mitarbeiter befindet, hat die stärkste „Bindung“ und bekommt die meiste Kapazität des Mitarbeiters zugeteilt, idealerweise 100%. Nur in Ausnahmefällen arbeitet ein Mitarbeiter für mehrere Teams (Extended-Team-Mitglied). Dabei regelt die Art des Teams (in P4 „Team-Flavor“ genannt), ob ein Team interdisziplinär mit Produktverantwortung arbeitet, teilweise interdisziplinär mit Komponenten-/Modulverantwortung oder als fachliche Gruppe, z.B. als Dienstleitungsteam einer bestimmten technischen Kompetenz.

Die fachliche Linie geht in den sogenannten “Communities-of-Practice“ auf, in denen sich die Mitarbeiter inhaltlich austauschen, wo Ausbildung stattfindet, sowie Technologien und Werkzeuge gepflegt und weiterentwickelt werden.

Teams, die zusammen an gleichen Produkten arbeiten organisieren sich im sogenannten Cluster, ähnlich dem „Agile Release Train“, dem „Value Stream“ oder der „Programm-Ebene“ in anderen agilen Frameworks. Die Gesamtorganisation besteht aus mehreren Clustern, die unterschiedliche Produktbereiche verantworten. Hierdurch entsteht eine hohe Kohärenz der Ziele und Verantwortung der Teams im Cluster.

In P4 gibt es keine Projekte, keine Projektleiter und keine Projektteams. Inhalte von Produktentwicklungsvorhaben werden in den Backlogs der Organisation, der Cluster und der Teams dargestellt. Am ehesten entsprechen den Projekten die auf Portfolio-Ebene geplanten System- oder Applikationsversionen (Releases).

Weiterlesen? Wie wird P4 eingeführt (Eine agile Reise).

.


Prinzipien des P4-Frameworks | Neuigkeiten FAQs  |  Hauptseite


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