D³
D³ Guide
Das praktische Handbuch für Decision-Driven Delivery.
01
Quick Start
Montag, 9 Uhr. Los.
Drei Schritte, um Decision-Driven Delivery diese Woche einzuführen. Kein Training, kein Zertifikat, kein Tool-Setup.
01
Entscheidungen sammeln
Setzen Sie sich mit Ihrem Team 30 Minuten zusammen. Fragen Sie: „Welche Entscheidungen stehen offen, die beeinflussen, was wir diese und nächste Woche bauen?“ Schreiben Sie jede Antwort auf. Nicht filtern, nicht bewerten. Sie werden überrascht sein, wie viele es sind — und wie viele davon niemand explizit verantwortet.
02
Decision Map anlegen
Tragen Sie die Entscheidungen in eine Tabelle ein. Fünf Spalten: Verstehen, Entscheiden, Umsetzen, Prüfen, Lernen. Jede Entscheidung bekommt eine Zeile und wird in die Spalte gesetzt, die ihren aktuellen Zustand beschreibt. Das ist Ihre erste Decision Map. Eine Tabelle reicht. Kein spezielles Tool nötig.
03
Erste Entscheidung durchziehen
Wählen Sie die Entscheidung mit der größten strategischen Tragweite. Nicht die dringendste — die wichtigste. Arbeiten Sie diese eine Entscheidung durch alle fünf Modi. Das dauert je nach Thema einen Tag bis eine Woche.
Danach wissen Sie, ob D³ für Ihr Team funktioniert. Nicht weil Sie es gelesen haben, sondern weil Sie es getan haben.
02
Die Decision Map
Das zentrale Steuerungsinstrument.
Die Decision Map ersetzt das Product Backlog. Sie zeigt nicht, was noch zu tun ist — sie zeigt, was noch zu entscheiden ist und in welchem Zustand sich jede Entscheidung befindet.
| Entscheidung | Owner | Verstehen | Entscheiden | Umsetzen | Prüfen | Lernen |
|---|
| Authentifizierungslösung | M. Schmidt | ✓ | ✓ | ● | | |
| Cloud-Provider | E. Yilmaz | ✓ | ● | | | |
| Datenmigrationsstrategie | — | ● | | | | |
| API-Versionierung | T. Weber | ✓ | ✓ | ✓ | ✓ | ● |
| Monitoring-Stack | K. Braun | ✓ | ✓ | ✓ | ● | |
● = aktuelle Phase · ✓ = abgeschlossen · — = kein Owner zugewiesen
Sortierung nach Tragweite, nicht Dringlichkeit
Strategische Entscheidungen stehen oben. Taktische unten. Ein unentschiedener Cloud-Provider blockiert mehr als ein offener Button-Text.
Maximal 15 aktive Entscheidungen
Wenn die Map mehr als 15 Einträge hat, sind entweder Entscheidungen zu granular oder das Team arbeitet an zu vielen Fronten. Beides ist ein Signal.
Jede Entscheidung braucht einen Owner
Wenn niemand verantwortlich ist, wird nicht entschieden. Ein „—“ in der Owner-Spalte ist ein Warnsignal, kein Normalzustand.
Entscheidungen in „Lernen“ verlassen die Map
Die Map zeigt nur aktive Entscheidungen. Abgeschlossene wandern in ein Archiv — sie werden bei Revisionen wieder relevant.
03
Entscheidungen schreiben
Das Dokument, das mehr wert ist als hundert Tickets.
Jede Entscheidung wird als eigenständiges Dokument festgehalten. Nicht als Nebensatz im Meeting-Protokoll. Nicht als Kommentar im Ticket. Als Dokument mit Struktur.
Decision Record
Titel
Präzise Frage, nicht Antwort.
Welche Authentifizierungslösung für Firmenkunden?
Status
Aktueller Modus.
Umsetzen
Owner
Wer verantwortet diese Entscheidung?
M. Schmidt (Tech Lead)
Kontext
Warum steht diese Entscheidung an?
Bestandssystem nutzt Session-basierte Auth. Neue Anforderung: SSO für Firmenkunden mit eigenem IdP. Regulatorische Anforderung: MFA bis Q3.
Optionen
Welche Alternativen wurden untersucht?
A) Keycloak On-Prem — volle Kontrolle, höherer Betriebsaufwand
B) Auth0 Managed — schneller Start, Vendor Lock-in
C) Eigenentwicklung auf Spring Security — maximale Flexibilität, höchstes Risiko
Entscheidung
Was wurde gewählt und warum?
Option A: Keycloak. Begründung: Regulatorische Anforderungen schließen Cloud-only aus. Team hat Keycloak-Erfahrung aus KBM-Projekt.
Verworfen
Was wurde nicht gewählt und warum?
Auth0: Daten dürfen nicht in US-Cloud. Eigenentwicklung: Risiko-Nutzen-Verhältnis bei gegebener Timeline nicht vertretbar.
Konsequenzen
Was folgt aus dieser Entscheidung?
Betriebsteam muss Keycloak-Cluster aufsetzen. Schulung für 2 Entwickler nötig. Migrationspfad für Bestandsnutzer definieren.
Revisionsbedingung
Wann diese Entscheidung überdenken?
Wenn regulatorische Anforderungen Cloud-Hosting explizit erlauben. Wenn Keycloak-Betriebskosten > 3x Auth0-Lizenzkosten.
Schreiben Sie den Titel immer als Frage. „Keycloak“ ist keine Entscheidung — „Welche Authentifizierungslösung für Firmenkunden?“ ist eine.
04
Die fünf Modi
In der Geschwindigkeit, die die Entscheidung braucht.
Jede Entscheidung durchläuft diese fünf Modi. Eine taktische Entscheidung braucht Stunden. Eine strategische Architekturentscheidung braucht ein bis zwei Wochen. Der Rhythmus folgt der Entscheidungslage, nicht dem Kalender.
Verstehen
Stunden bis Tage
Lösungsraum erkunden. Optionen identifizieren. Risiken bewerten.
- —Recherche: Was gibt es? Was haben andere gemacht?
- —Prototypen: Proof of Concept, Spike, Machbarkeitsstudie
- —AI nutzen: Alternativen generieren, Trade-offs analysieren
- —Stakeholder befragen: Wer ist betroffen? Was sind die Rahmenbedingungen?
Output
Optionen-Dokument mit mindestens zwei realistischen Alternativen.
Verstehen endet nicht, wenn jemand eine Meinung hat. Es endet, wenn die Optionen dokumentiert sind.
Entscheiden
Minuten bis Stunden
Bewusst wählen. Dokumentieren. Verantworten.
- —Owner trifft die Entscheidung — nicht das Komitee
- —Decision Record schreiben (siehe Template oben)
- —Verworfene Optionen dokumentieren — genauso wichtig wie die Wahl
- —Revisionsbedingung festlegen: Wann überdenken wir das?
Output
Ausgefülltes Decision Record.
Eine Entscheidung, die nicht dokumentiert ist, wurde nicht getroffen. Sie wurde nur besprochen.
Fokussiert bauen, was entschieden wurde.
- —Scope ist klar: Die Entscheidung definiert, was gebaut wird
- —AI-Werkzeuge für Code-Generierung, Boilerplate, Tests nutzen
- —Kein Scope Creep: Neue Fragen → neue Entscheidung auf die Map
- —Fortschritt messen am Ergebnis, nicht an der Aktivität
Output
Implementierung, die der Entscheidung entspricht.
Wenn während der Umsetzung die Architektur „nochmal kurz“ geändert wird, war die Entscheidung nicht sauber getroffen.
Ergebnis gegen Entscheidung messen.
- —Nicht fragen: „Ist das Ticket erledigt?“ Sondern: „Hält das, was die Entscheidung versprochen hat?“
- —Last-Tests, Security-Review, Fallback-Szenarien testen
- —Stakeholder-Feedback: Entspricht das der Erwartung?
- —Automatisierte Tests, die die Entscheidung absichern — nicht nur den Code
Output
Validierungsergebnis: bestanden / Nacharbeit / Entscheidung überdenken.
„Funktioniert auf meinem Rechner“ ist keine Prüfung.
Erkenntnis zurückführen. Archivieren.
- —Was haben wir über die Entscheidung gelernt?
- —Stimmt die Annahme noch?
- —Was würden wir beim nächsten Mal anders machen?
- —Decision Record mit Learnings ergänzen, in Archiv verschieben
Output
Ergänztes Decision Record im Archiv.
„Lernen“ überspringen, weil die nächste Entscheidung drängt. Genau dann verpasst man die wichtigste Erkenntnis.
05
Triage
Bug, Lücke oder falsche Entscheidung?
Wenn etwas schiefgeht, gibt es drei mögliche Ursachen. Die Triage unterscheidet sie, weil die Antwort jeweils anders ist.
Bug
Wurde die Entscheidung korrekt umgesetzt?
Nein — die Implementierung weicht von der Entscheidung ab.
Fix. Zurück in „Umsetzen“. Keine neue Entscheidung nötig.
Keycloak wurde konfiguriert, aber MFA-Enforcement fehlt in der Staging-Umgebung.
Lücke
Wurde ein Aspekt übersehen?
Ja — die Entscheidung war richtig, aber unvollständig.
Ergänzen. Decision Record erweitern. Fehlenden Aspekt umsetzen.
Keycloak funktioniert, aber Session-Timeout für Firmenkunden wurde nicht spezifiziert.
Revision
War die Entscheidung selbst falsch?
Ja — die Annahmen haben sich als falsch herausgestellt.
Neue Entscheidung. Zurück auf die Map in „Verstehen“. Alte Entscheidung archivieren.
Keycloak-Betriebskosten liegen 4x über der Schätzung. Revisionsbedingung ist eingetreten.
Die Triage dauert fünf Minuten. Die meisten Teams überspringen sie und behandeln alles als Bug. Das ist der Grund, warum dieselben Probleme wiederkommen.
06
Rollen im Alltag
Was tun diese Menschen eigentlich den ganzen Tag?
Drei Rollen, definiert über eine Frage: Wer trifft welche Entscheidungen?
Decision Owner
~ Product Owner
- —Montag: Decision Map reviewen — was steht an, was ist überfällig?
- —Dienstag–Donnerstag: Kontext liefern. Stakeholder-Gespräche. Geschäftsperspektive einbringen.
- —Freitag: Validation Review — stimmen die Ergebnisse mit den Erwartungen überein?
Formuliert die richtigen Fragen. Nicht „Baue ein Login“, sondern „Wie authentifizieren sich Firmenkunden sicher und komfortabel?“
Decision Architect
~ Scrum Master
- —Montag: Map-Status prüfen. Blockaden identifizieren. Abhängigkeiten erkennen.
- —Täglich: Entscheidungsprozess steuern. Dafür sorgen, dass Entscheidungen weder verschleppt noch überstürzt werden.
- —Freitag: Decision Records auf Vollständigkeit prüfen. Archiv pflegen.
Schützt den Prozess. Wenn eine Entscheidung seit drei Wochen in „Verstehen“ hängt, ist das sein Problem.
Decision Maker
~ Developer
- —Montag: Aktuelle Entscheidungen sichten. Lösungsraum verstehen.
- —Dienstag–Donnerstag: Untersuchen, entscheiden, umsetzen, prüfen. AI-Werkzeuge nutzen.
- —Freitag: Learnings dokumentieren. Decision Records ergänzen.
Die Kernleistung ist nicht Code, sondern Entscheidungskompetenz. KI-Werkzeuge sind Handwerkszeug.
07
Rituale
Drei feste Termine. Nicht mehr.
D³ hat weniger Rituale als Scrum. Kein Daily, kein Sprint Planning, keine Retrospektive als separates Event.
Map Review
Montags · 30 Min
Decision Owner + Architect
- —Welche Entscheidungen sind neu?
- —Welche sind blockiert?
- —Welche haben keinen Owner?
- —Stimmt die Reihenfolge?
Aktualisierte Decision Map.
Validation Review
Freitags · 45 Min
Alle drei Rollen
- —Welche Entscheidungen wurden validiert?
- —Stimmen die Ergebnisse?
- —Was haben wir gelernt?
- —Revisionsbedarf?
Validierte → Archiv. Learnings → dokumentiert. Revisionen → Map.
Architect + Decision Maker
- —Bug, Lücke oder Revision?
- —Sofortige Zuordnung
Klare nächste Aktion.
08
AI im Workflow
Das „wie“ statt des „ob“.
KI-Werkzeuge verändern, was ein einzelner Entwickler leisten kann — und damit, was eine Entscheidung kostet und wie schnell sie umgesetzt wird.
Verstehen
Alternativen generieren. Prototypen bauen. Trade-off-Analysen.
„Vergleiche Keycloak, Auth0 und Eigenentwicklung nach Kosten, Vendor Lock-in und Compliance.“
Entscheiden
Decision Record vorbereiten. Konsequenzen-Analyse.
„Fasse die Keycloak-PoC-Ergebnisse zusammen und formuliere ein Decision Record.“
Umsetzen
Code-Generierung. Boilerplate. Test-Scaffolding.
„Implementiere die Keycloak-Integration gemäß Decision Record. Spring Boot, MFA-Enforcement.“
Prüfen
Test-Generierung. Security-Scans. Last-Simulationen.
„Generiere Integrationstests: MFA erzwungen, Session-Timeout 30 Min, Firmenkunden-SSO.“
Lernen
Learnings zusammenfassen. Muster erkennen.
„Analysiere die letzten fünf Entscheidungen. Welche Muster bei den Revisionsbedingungen?“
KI beschleunigt jeden Modus. Aber sie trifft keine Entscheidungen. Die Verantwortung bleibt beim Menschen.
09
Metriken
Was Sie messen sollten — und was nicht.
D³ misst nicht, wie viel das Team geschafft hat. Es misst, wie gut das Team entschieden hat.
Decision Cycle Time
Wie lange von „Verstehen“ bis „Lernen“? Je kürzer, desto schneller lernt das Team.
Decision Backlog Age
Wie viele Entscheidungen sind seit über zwei Wochen offen? Steigende Zahlen = Entscheidungsstau.
Owner Coverage
Prozent der Entscheidungen mit klarem Owner. Unter 100% ist ein Warnsignal.
Revisionsrate
10–20% ist gesund. Null = niemand prüft. Über 30% = Verstehen-Phase zu dünn.
Velocity / Story Points
Misst Aktivität, nicht Ergebnis.
Lines of Code
Im AI-Zeitalter bedeutungslos.
Entscheidungen pro Woche
Fördert Quantität statt Qualität.
10
Migration von Scrum
Kein Big Bang. Vier Wochen.
D³ ersetzt Scrum nicht über Nacht. Die Migration funktioniert als schrittweiser Übergang, parallel zum bestehenden Prozess.
Woche 1
Entscheidungen sichtbar machen
- —Erste Decision Map anlegen (neben dem Backlog)
- —Offene Entscheidungen identifizieren, die als Tickets getarnt sind
- —Rollen zuweisen: Wer ist Owner, wer Architect?
Woche 2
Erste Entscheidungen durchziehen
- —Zwei bis drei Entscheidungen durch alle fünf Modi
- —Erste Decision Records schreiben
- —Sprint Review um Decision Review ergänzen
Woche 3
Steuerung umstellen
- —Decision Map wird primäres Steuerungsinstrument
- —Tickets bleiben für Umsetzung, Priorisierung kommt von der Map
- —Erste Triage: Bug, Lücke oder Revision?
Woche 4
Scrum-Rituale ersetzen
- —Sprint Planning → Map Review (Montag)
- —Sprint Review → Validation Review (Freitag)
- —Daily → optional
- —Retrospektive → in Validation Review integriert
Nach vier Wochen entscheiden Sie: Funktioniert D³ besser als das, was vorher war? Die Antwort liegt in der Decision Map.