About P4

Das P4-Dev-Framework beschreibt eine neue Art der Organisationsstruktur für den Bereich der Produktentwicklung für Organisationen, die physische Produkte entwickeln und produzieren. 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 neue Rollen, Artefakte und Events gemäß den Scrum-Prinzipien definiert.

P4 gliedert sich (wie Scrum) 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 der Teams
  • Events: Zeiträume und Meetings, sowie deren Inhalte

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

  • Toyota Product Development System: kontinuierlicher Arbeitsfluss und Pull-Prinzip
  • Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Nexus, Scrum@Scale: Skalierung von agilen Teams
  • Lean Startup: Schnelles Lernen und Adaptieren mit dem Markt
  • Design Thinking: Exploration des Problem- und Lösungsraums mittels schneller Generierung von Prototypen
  • Lean Product & Process Development (LPPD): Knowledge-based-development, Visible-Knowledge und Set-Based-design
  • Theory-of-Constraints und Critical-Chain: Die Regulierung von Arbeitsflüssen durch die Ausrichtung an, und die Optimierung von Flaschenhälsen (Constraints)

Warum noch ein agiles skalierendes Framework?

Obwohl es schon eine Reihe von Frameworks zur Skalierung von Agilität gibt, allen voran SAFe und LeSS, 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:

  • Die Backlog-Struktur und seine zum Teil neuen Elemente ermöglichen Systemeentwicklungen von physischen Produkten und stellen einen Vorgehensleitfaden dar. Inbesondere das Konzept der Wissenlücken (Knowledge-Gaps) ermöglicht die strukturierte wissenbasierte Entwicklung und iteratives Lernen.
  • Die P4-Organisationsstruktur berücksichtigt nicht nur interdisziplinäre (cross-functional) Teams, sondern auch Modul- und Komponententeams, sowie Teams, die eine spezielle Disziplin als Dienstleistung zur Verfügung stellen. Die hohe Spezialisierung in der modernen Systementwicklung macht die verschiedenen Arten von Teams notwendig. Im P4-Framework nennen wir diese Team-Arten “Team-Flavors”.
  • Das in P4 integrierte Zusammenarbeitungsmodell aus Nucleus, Extended-Team, Supporter und Stakeholder, ermöglicht es, dass Experten mit mehreren Teams arbeiten können.

Erweiterungen

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

Da es sich bei P4 um ein Rahmenwerk handelt, können weitere nutzbringende und als nötig erachtete Praktiken und Methoden 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 Vorgesetzen (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 eine, ü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). 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 “Practices“ 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 in sogn. Clustern, ähnlich den “Agile Release Trains”, “Value Streams” oder der “Programm-Ebene” in anderen agilen Frameworks. Die Gesamtorganisation besteht aus mehreren Clustern, die unterschiedliche Produktbereiche verantworten. Hierdurch entsteht eine hohe Koheränz der Ziele und Verantwortung der Teams im Cluster.