Disciplined Agile Delivery (DAD) ist ein hybrides Prozess-Framework für die Software- und Produktentwicklung. Es wurde von Scott W. Ambler und Mark Lines entwickelt und ist heute Bestandteil des Disciplined Agile (DA) Toolkits des Project Management Institute (PMI). DAD integriert Praktiken aus Scrum, Kanban, Lean, XP, Agile Modeling und Agile Data und deckt den End-to-End-Delivery-Lebenszyklus ab – von Inception (Initiierung) über Construction (Bau) bis Transition (Betriebseinführung).
Ursprung und Zweck
DAD entstand, um die Grenzen rein teamzentrierter Frameworks zu überwinden. Ziel war es, Organisationen zu ermöglichen, ihren Way of Working (WoW) kontextspezifisch zu gestalten – auf Basis von Zielen, Entscheidungsmöglichkeiten und Trade-offs. Mit der Übernahme durch das PMI (2019) wurde DAD in das breitere DA-Toolkit integriert.
Kernelemente
- Lebenszyklen (Lifecycles):
- Agile Lifecycle (Scrum-basiert)
- Lean Lifecycle (Kanban-basiert)
- Continuous Delivery: Agile Lifecycle
- Continuous Delivery: Lean Lifecycle
- Exploratory Lifecycle (Lean-Startup-inspiriert)
- Program Lifecycle (koordiniert mehrere Teams)
- Process Goals & Goal Diagrams: Ergebnisorientierte Ziele (z. B. „Prove Architecture Early“, „Address Risk“, „Evolve Solution“), die unterschiedliche Vorgehensoptionen und deren Konsequenzen aufzeigen.
- Rollen:
- Primär: Team Lead (Weiterentwicklung des Scrum Masters), Product Owner, Architecture Owner, Team Members
- Sekundär (optional): Independent Tester, Domain/Technical Experts, Integrator
- Enterprise Awareness: Fokus auf Integration von Governance, Architektur, Datenmanagement, Security und Betrieb.
- DevOps-Verzahnung: Enge Verbindung mit CI/CD, Testautomatisierung und operativem Feedback.
Anwendung und Best Practices
- Kontext statt Dogma: Teams wählen Praktiken bewusst anhand von Prozesszielen und Organisationsumfeld.
- Just-enough Inception: Architektur-Risiken früh adressieren (Spikes, Walking Skeleton), ohne Big Design Upfront.
- Engineering-Exzellenz: CI/CD, Testautomatisierung, WIP-Limits und Flow-Metriken sind Voraussetzung für DAD-Erfolg.
- Architektur moderiert statt diktiert: Architecture Owner fördert inkrementelle Architekturentscheidungen und dokumentiert „just enough“.
- Outcome-orientierte Governance: Guardrails definieren, Metriken auf Wert und Risiken statt Output ausrichten.
- Lifecycle-Wechsel zulassen: Teams dürfen – gesteuert – zwischen Lifecycles wechseln (z. B. Exploratory → Continuous Delivery), wenn es die Lernsignale erfordern.
Praxisbeispiele
Finanzsektor: Kombination aus agilem Lifecycle (fachnahe Teams) und leanem Lifecycle (Plattformteams). Compliance wurde über leichte Controls (Definition of Done-Erweiterungen, Evidence by Automation) abgesichert.
Medizintechnik: Exploratory Lifecycle für frühe klinische Hypothesen, später Wechsel in Continuous Delivery: Agile Lifecycle. Risikobasierte Tests stellten regulatorische Nachweise sicher.
Großprogramme: Einsatz des Program Lifecycles. Ein Architecture-Owner-Circle koordinierte Schnittstellen, während lokale Kanban-Policies Flussoptimierung erlaubten.
Legacy-Modernisierung: Brücke zwischen Scrum-Teams (Features) und Kanban-Teams (Core Services) durch gemeinsame Process Goals und Architektur-Roadmaps.
Kritik und Grenzen
- Komplexität: Das breite Toolkit und die Vielzahl an Goal Diagrams erzeugen hohe Einarbeitungskosten. Ohne Coaching droht „Choice Fatigue“.
- Gefahr des „Frankenstein-Prozesses“: Unreflektiertes Kombinieren widersprüchlicher Praktiken führt zu Inkonsistenzen, Wartezeiten und lokalen Optimierungen.
- Rollenunklarheiten: Team Lead vs. Scrum Master, Architecture Owner vs. emergente Architektur – schlecht moderiert, verzögern sich Entscheidungen und Architekturen erodieren.
- Missverständnisse bei Phasen: Inception und Transition werden fälschlich als Stage-Gates interpretiert, was zu Wasserfall-ähnlichen Rückfällen führt.
- Governance-Last: In regulierten Sektoren hilfreich, in KMU oder Start-ups schnell überprozedural. Outcome-basierte Governance ist Pflicht.
- Abhängigkeit von Technikreife: Ohne CI/CD, Automatisierung und Enabler-Kapazitäten gerät DAD in Dokumentations- und Meeting-Schleifen.
- Geringere Community-Dichte: Weniger verbreitet als SAFe; dadurch weniger Fallstudien, Benchmarks und Trainingsangebote.
- Portfolio-Lücke: DAD bietet Program-Lifecycle, aber keine explizite Portfolio-/Value-Stream-Governance. Organisationen müssen ergänzende Mechanismen (z. B. Portfolio-Kanban, Lean Budgeting) schaffen.
Einbettung und Kombination
- Scrum/Kanban/XP: DAD integriert diese Praktiken, ersetzt sie nicht.
- SAFe/LeSS/Nexus: DAD ist flexibler und kontextspezifischer, bietet aber weniger „vorkonfigurierte“ Guidance.
- DevOps & Data: Systematisch integriert über Process Goals.
- Living Transformation®/Living Strategy: DAD liefert Methodenvielfalt, während Living Transformation® und Living Strategy strategische Steuerung und Outcome-Fokus sichern.
CALADE-Perspektive
Wir nutzen DAD pragmatisch in Kontexten mit hoher Komplexität oder starker Regulierung. CALADE unterstützt beim Navigieren der Goal Diagrams, beim Aufbau von Guardrails (Architektur, Security, Data) und bei der Integration in Portfolio-Steuerung. So entsteht ein passgenauer Way of Working – ohne Framework-Dogma.
Verweise auf verwandte Glossarartikel
- Scrum
- Kanban
- SAFe
- LeSS
- Nexus
- Lean Portfolio Management
- Built-in Quality
- DevOps
- Living Transformation®
- Living Strategy
← zurück zur Übersicht