Die agile Bewegung kommt häufig in die Kritik, bezüglich ihrer Prinzipien zu dogmatisch zu sein. Viele dieser Prinzipien lassen sich im Verbund mehrerer Teams und innerhalb großer Organisationen nur eingeschränkt halten. Dies hat sich in der Vergangenheit bei der praktischen Umsetzung häufig gezeigt, was einer der Hauptkritikpunkt von „agilen Puristen“ an agilen Skalierungsrahmenwerken ist, die dieses Problem zu lösen suchen. Die Pragmatische Produktentwicklung versucht daher bewusst eine Balance aus „so agil, wie möglich“ und „so strukturiert, wie nötig“ herzustellen.
Die folgende Tabelle listet und vergleicht die unterschiedlichen Attribute der klassischen, agilen und pragmatischen Ansätze:
| Attribut | Agil | Klassisch | Pragmatisch (z.B. P4) |
| Management-Verantwortung: | Flache Hierarchie, Verantwortung durch PO, SM und Working-Team | Eindimensionale Hierarchie und Verantwortung | Drei (bzw. vier) klar getrennte Verantwortungsbereiche (Trinity of management) |
| Teams: | x-funktional | funktionale Silos | Applikations- und Featureteams sind x-funktional; Modul- und Plattformteams ebenfalls, soweit möglich und nötig. Service- und Experten-Teams sind weiterhin funktional aufgestellt. |
| Zuordnung: | Zuordnung zu 100% | Fragmentierte Mitarbeit: Mehrere Projekte pro Mitarbeiter | 100% Zuordnung, wenn möglich und sinnvoll: Nucleus (ein Team), Extended-Team-Mitglied (für wenige Teams), Supporter (mehrere Teams, nach Bedarf) |
| Specialization: | Generalisten | Spezialisten | Generalisten und Experten, je nach Team-Art und Bedürfnissen |
| Strukturen und Frameworks: | Idealerweise keine Frameworks | Vordefinierte Strukturen definieren die Teams | Rahmenwerk mit Leitprinzipien für Teamstrukturen, Wertströme und den Arbeitsfluss. |
| Team-Koordination: | „Dailies“ jeden Tag | nach Bedarf oder wöchentlich | Nucleus stimmt sich täglich ab, Extended Teammitglieder kommen zum Team-Sync je einen Tag/Woche pro 20% Zuordnung. |
| Prozess: | kein oder wenig Prozess | Genau definierter und schwergewichtiger Prozess | Minimal Prozess. Benötigte Dokumentation ist Teil des System-Inkrements und des Applikations-Release. |
| Vorgehen und Fortschritt: | funktional (Feature-driven) | Plan getrieben (Aufgaben- und Zeitplan) | Wissensgetrieben: Verwandelt Wissenslücken in nutzbares Wissen und dokumentierte Entscheidungen |
| Planung und Vorbereitung (Frontloading): | minimal | intensive Anforderungserhebung und Planung | Limitiert durch was wir wissen (Hypothesen), Optionen und was wir nicht wissen (Knowledge Gaps) |
| Produktreife: | anhand von komplett fertigen Produktfunktionen | vorab geplante Reifegrade und Meilensteine | inhaltsbasierte Reife anhand von Funktionalität und Wissenslücken |
Basierend auf unseren Erfahrungen balanciert Pragmatic Product Development die Prinzipien von Lean und Agile Frameworks mit den Anforderungen größerer Organisationen, insbesondere der physischen Produktentwicklung (gleichartige Strukturen, regulierte Prozesse, der Umgang mit Experten und gemeinsam genutzten Testlaboren).
Was fehlt in agilen Frameworks und wie geht P4 damit um?
Agile Frameworks, wie Scrum, definieren bewusst nicht alle Praktiken. Diese sollen situativ von den Organsationen und Teams hinzugenommen werden. Im Vergleich mit klassischen, projekt- und plangeriebenen Ansätzen fehlen folgende Praktiken:
- Risikomanagement: Es gibt kein explizitest Risikomanagement in Scrum, mit der Ausnahme der Risikobetrachtung bei der Priorisierung von Backlog-Einträgen. In P4 wird ein explizites Risikomanagement für die Entwicklung des Produkts (sogn. Umsetzungsrisiken) und die Nutzung des Produkts (Produktrisiken)empfohlen.
- Ausbildung und Training von Mitarbeitern: In P4 wird das im Rahmen der Retrospektiven betrachtet und Aktivitäten in den Improvement-Backlogs dargestellt.
- Change-Management: Tatsächlich gibt es in agilen Ansätzen kein explizites Change-Management, da von vornherein von ständigen Änderungen (Erweiterungen, Streichungen und Anpassungen) ausgegangen wird. Man könnte auch sagen, dass die Arbeit am Bocklog ein permanentes Change-Management darstellt.
Was fehlt in klassischen Ansätzen?
- Fokus auf Wertschöpfung: Der Wert eines plangetriebnen Projekts wird meist dadurch vorweggenommen, dass das Projekt überhaupt gestartet wurde. Damit wird die Definition des Werts auf die Programm- und Portfolioebene limitiert, da die Festlegung des Projektumfangs (Scope) meist hier vordefiniert wird.
- Chancen-Management: Während eines plangetriebenen Projekts wird neben dem Risikomanagement meist kein Chancen-Management betrieben. Auch hier wird meist vorausgesetzt, dass dies vor dem Projektstart auf Programm- und Portfolioebene betrachtet wurde.
(Titelbild von pch.vector auf freepik)
Nächster Artikel: „Wenn es doch ein Projekt sein muss …“ | Zurück zu den FAQ | Hauptseite