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:
- Toyota Product Development System: kontinuierlicher Arbeitsfluss und Pull-Prinzip
- Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Nexus, Scrum@Scale: Skalierung von agilen Teams
- The 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, 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 P4-Organisationsstruktur berücksichtigt nicht nur interdisziplinäre (cross-functional) Teams mit Feature-, Produkt- oder Applikationsverantwortung, sondern auch zuliefernde Modul-, Komponenten- und Plattform-Teams, sowie Teams, die eine spezielle Expertise als Dienstleistung anderen Teams 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“.
- Neben den Rollen Product-Owner und Scrum-Master führt P4 die Rolle des System-Engineer ein, in der die Verantwortung für Technologie und Architektur eines Teams gebündelt wird. Der Team-System-Engineer vertritt darüber hinaus die technologische Expertise seines Teams auf der nächst höheren Skalierungsebene.
- Für die Aus- und Weiterbildung von Mitgliedern interdisziplinärer Teams, sowie der gemeinsamen Weiterentwicklung von intern genutzten Werkzeugen, integriert P4 die Ideen von Communities-of-Practice.
- Auf den Skalierungsebenen (Cluster und Organisation) werden Gruppen aus Mitgliedern der „niedrigeren“ Ebene gebildet. Durch dieses Überlappungsprinzip werden Informationsflüsse zwischen den Ebenen vereinfacht. Events der beteiligten Ebenen müssen dafür entkoppelt werden, wofür die sogn. Cadence sorgt, die eine Art „Stundenplan“ der Organisation darstellt.
- Die Backlog-Struktur und seine zum Teil neuen Elemente unterstützen Systementwicklungen von physischen Produkten und stellen einen Vorgehensleitfaden dar. Inbesondere das Konzept der Wissenslücken (Knowledge-Gaps) ermöglicht die strukturierte wissensbasierte Entwicklung und iteratives Lernen.
- Das in P4 integrierte Zusammenarbeitsmodell aus Nucleus, Extended-Team, Supporter und Stakeholder, erweitert das einfache Scrum-Modell (Mitarbeiter sind ganz oder gar nicht im Team) und unterstützt damit die Zusammenarbeit von Experten mit mehreren Teams. Dabei ist die Zusammenarbeit komplett in die Events der Organisation 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-Product-Owner
. . |
Working-Team
. . |
Team-Backlog
. Nutzbares-Wissen & System-Inkrement . |