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).
(Titelbild von pch.vector auf freepik)
Nächster Artikel: „Wenn es doch ein Projekt sein muss …“ | Zurück zu den FAQ | Hauptseite