Entscheidungen statt Tickets.

Stellen Sie sich vor, Sie beauftragen ein Architekturbüro mit dem Bau eines Hauses. Das Büro schickt Ihnen alle zwei Wochen einen Bericht: 47 Ziegel wurden diese Woche verlegt, 23 Meter Rohr installiert, die Velocity liegt bei 94%. Beeindruckende Zahlen.

Aber niemand hat Sie gefragt, ob das Haus überhaupt einen Keller braucht. Ob die Küche nach Süden zeigen soll. Ob der Grundriss zu Ihrer Familie passt.

Genau das passiert in den meisten IT-Projekten.

Was Scrum misst — und was es übersieht

Scrum wurde vor über zwanzig Jahren entwickelt. Es löste ein reales Problem: Softwareprojekte, die jahrelang im Verborgenen entstanden und am Ende nicht das lieferten, was gebraucht wurde. Scrum brachte Rhythmus, Transparenz und regelmäßiges Feedback. Das war ein Fortschritt.

Aber Scrum misst den Fortschritt eines Projekts an der Menge erledigter Aufgaben. An Tickets, Story Points, Velocity. Das funktioniert, solange das Schreiben von Software der Engpass ist — solange die Frage lautet: Schaffen wir genug?

Heute lautet die Frage anders. Künstliche Intelligenz kann in Stunden erzeugen, wofür ein Team früher Wochen brauchte. Code-Produktion ist nicht mehr knapp. Was knapp ist: die Fähigkeit, die richtigen Entscheidungen zu treffen.

Welche Architektur trägt langfristig? Welche Technologie passt zu unseren Rahmenbedingungen? Welche Anforderung ist wirklich geschäftskritisch, und welche ist nur laut?

Diese Fragen beantwortet kein Sprint Planning.

Die Perspektive umdrehen

Jedes Softwareprojekt ist im Kern eine Kette von Entscheidungen: Welche Datenbank verwenden wir? Wie authentifizieren sich die Nutzer? Soll das System synchron oder asynchron arbeiten? Bauen wir selbst oder kaufen wir ein?

Jede dieser Entscheidungen hat Konsequenzen. Sie öffnet Türen und schließt andere. Sie kostet Geld, wenn sie falsch getroffen wird, und noch mehr Geld, wenn sie zu spät getroffen wird.

Scrum behandelt all diese Fragen gleich: als Einträge im Backlog, abgearbeitet in Zwei-Wochen-Zyklen. Die strategische Architekturentscheidung steht neben dem Bugfix und dem UI-Feinschliff. Die Frage, ob die Authentifizierung überhaupt richtig konzipiert ist, konkurriert mit der Frage, ob der Button die richtige Farbe hat.

Was wäre, wenn man das trennt? Wenn man dem, was wirklich zählt — den Entscheidungen — eine eigene Steuerungsebene gibt?

Das ist die Idee hinter Decision-Driven Delivery.

Statt zu fragen „Wie viel haben wir geschafft?“ fragt es: „Welche Entscheidungen haben wir getroffen — und waren es die richtigen?“

Fünf Modi statt Zwei-Wochen-Takt

Ein Team, das nach Decision-Driven Delivery arbeitet, bewegt sich in fünf Arbeitsmodi. Nicht nacheinander wie in einer Wasserfall-Planung, sondern in schnellen Zyklen — pro Entscheidung.

Verstehen. Bevor eine Entscheidung getroffen wird, wird der Lösungsraum untersucht. Was sind die Optionen? Was spricht für jede, was dagegen? Welche Risiken bestehen? Hier kommen auch KI-Werkzeuge zum Einsatz: Sie generieren Prototypen, testen Machbarkeit, vergleichen Alternativen. Das Ergebnis ist kein Code, sondern Klarheit.

Entscheiden. Die Entscheidung wird bewusst getroffen, dokumentiert und verantwortet. Nicht als Nebensatz im Meeting-Protokoll, sondern als eigenständiges Dokument: Was wurde entschieden? Was wurde verworfen und warum? Unter welchen Umständen sollte die Entscheidung überdacht werden? Dieses Dokument hat mehr Wert als hundert Tickets.

Umsetzen. Jetzt wird gebaut — fokussiert auf das, was entschieden wurde. Kein Scope Creep, keine Seitenstraßen. KI-Werkzeuge beschleunigen die Umsetzung erheblich. Das Team konzentriert sich darauf, die Qualität des Ergebnisses sicherzustellen.

Prüfen. Hält das Ergebnis, was die Entscheidung versprochen hat? Nicht: Ist das Ticket erledigt? Sondern: Funktioniert die Authentifizierung unter Last? Ist der Fallback getestet? Können wir im Fehlerfall zurückrollen?

Lernen. Was haben wir über die Entscheidung gelernt? Stimmt die Annahme noch? Muss etwas korrigiert werden? Die Erkenntnis fließt zurück und beeinflusst kommende Entscheidungen.

Diese fünf Schritte sind kein Wasserfall. Sie dauern für eine taktische Entscheidung manchmal nur Stunden. Für eine strategische Architekturentscheidung vielleicht ein bis zwei Wochen. Der Unterschied zu Scrum: Der Rhythmus folgt der Entscheidungslage, nicht dem Kalender.

Was sich konkret ändert

Drei Rollen, eine Frage: Wer entscheidet?

Scrum kennt drei Rollen: Product Owner, Scrum Master, Entwickler. Decision-Driven Delivery definiert Rollen über eine andere Frage: Wer trifft welche Entscheidungen?

Decision Owner. Vergleichbar mit dem Product Owner, aber mit anderem Fokus. Er formuliert nicht „Baue ein Login-Formular“, sondern „Wie authentifizieren sich unsere Firmenkunden sicher und komfortabel?“ Er verbindet die Geschäftsperspektive mit der technischen Realität und verantwortet die Priorisierung: Welche Entscheidung hat die größte strategische Tragweite?

Decision Architect. Vergleichbar mit dem Scrum Master, aber statt Rituale zu moderieren, steuert er den Entscheidungsprozess. Er sorgt dafür, dass Entscheidungen weder verschleppt noch überstürzt werden. Er erkennt Abhängigkeiten, schützt das Team vor Überlastung und stellt sicher, dass jede Entscheidung sauber dokumentiert wird.

Decision Maker. Das sind die Fachleute — Entwickler, Architekten, Spezialisten. Ihre Kernleistung ist nicht Code, sondern Entscheidungskompetenz. Sie untersuchen den Lösungsraum, bereiten technische Entscheidungen vor, treffen Architekturentscheidungen eigenverantwortlich und setzen sie um. KI-Werkzeuge sind ihr Handwerkszeug — nicht ihr Ersatz.

Die Decision Map

In Scrum ist das zentrale Steuerungsinstrument das Product Backlog: eine nach Priorität sortierte Liste von Aufgaben. In Decision-Driven Delivery ist es die Decision Map.

Die Decision Map zeigt auf einen Blick: Welche Entscheidungen stehen an? Welche sind in Untersuchung, welche entschieden, welche umgesetzt und geprüft? Wo gibt es Abhängigkeiten? Was blockiert?

Die zentrale Steuerungsfrage wechselt. Statt „Wie viele Story Points haben wir geschafft?“ heißt sie: „Welche strategischen Entscheidungen sind offen, und was fehlt, um sie zu treffen?“

Für Führungskräfte hat das einen entscheidenden Nebeneffekt: Die Decision Map macht den tatsächlichen Zustand eines Projekts sichtbar. Nicht in abstrakten Velocity-Kurven, sondern in konkreten Fragen: Ist die Architekturentscheidung getroffen? Ist die Compliance-Frage geklärt? Warten wir auf eine Entscheidung des Vorstands?

Das Alltagsproblem: Ungeplante Arbeit

Einer der häufigsten Schmerzpunkte in Scrum ist der Umgang mit Störungen. Ein Sprint wird geplant, dann kommt ein Hotfix, dann meldet die Qualitätssicherung Fehler, dann eskaliert ein Kunde. Am Freitag ist das Sprint-Ziel verfehlt.

Das passiert, weil der Sprint der einzige Container ist, den Scrum kennt. Es gibt keine strukturelle Unterscheidung zwischen einer strategischen Architekturentscheidung und einem kaputten Layout.

Decision-Driven Delivery trennt ungeplante Arbeit nach ihrem tatsächlichen Charakter:

Stufe 1 — Einfache Korrektur. Ein klar identifizierbarer Fehler mit bekannter Ursache. Wird direkt behoben, ohne den Entscheidungsprozess zu berühren.

Stufe 2 — Umsetzungslücke. Das Ergebnis erfüllt die zugrundeliegende Entscheidung nicht vollständig. Die Umsetzung wird nachgebessert — innerhalb des bestehenden Rahmens.

Stufe 3 — Revisionssignal. Wiederkehrende Probleme im selben Bereich. Das ist kein Bug mehr — das ist ein Signal, dass eine getroffene Entscheidung überdacht werden muss. Eine neue Untersuchung wird eingeleitet.

Diese Unterscheidung verhindert zwei Dinge: dass Teams unter dem Deckmantel eines Bugfixes die Architektur umbauen, ohne dass jemand es merkt. Und dass echte Warnsignale als „normaler Bug“ abgetan werden.

KI ist kein Werkzeug am Rand

Künstliche Intelligenz ist in Decision-Driven Delivery kein optionales Feature, sondern integraler Bestandteil. Aber nicht als Ersatz für menschliche Entscheidungen, sondern als Verstärker.

In der Exploration generiert KI Prototypen, vergleicht Alternativen und komprimiert den Informationsraum. In der Umsetzung schreibt KI Code, Tests und Dokumentation — schneller als jedes menschliche Team. In der Prüfung erkennt KI Muster, die auf Probleme hindeuten.

Was KI nicht tun kann: die Verantwortung für eine Entscheidung übernehmen. Wenn ein KI-Werkzeug eine Architektur vorschlägt und diese unter Last zusammenbricht, haftet nicht die KI. Die Entscheidung, dieser Empfehlung zu folgen, liegt beim Menschen — und wird als solche dokumentiert.

Was es für Auftraggeber bedeutet

Decision-Driven Delivery verändert auch, wie Softwareprojekte beauftragt und abgerechnet werden. Das klassische Modell — Tagessätze für Entwickler, abgerechnet nach Aufwand — erzeugt einen falschen Anreiz: Je länger ein Projekt dauert, desto mehr verdient der Dienstleister.

Phase 1: Klarheit schaffen. In ein bis zwei Wochen werden alle strategischen Entscheidungen für ein Vorhaben getroffen und dokumentiert. Der Auftraggeber erhält eine vollständige Entscheidungslandkarte mit Architekturempfehlung. Festpreis. Danach kann er mit jedem beliebigen Partner — oder intern — weiterarbeiten.

Phase 2: Ergebnis liefern. Die Umsetzung wird nicht nach Aufwand berechnet, sondern pro konkretem Ergebnis. Nicht „200 Entwicklerstunden“, sondern „Authentifizierungsschicht mit SSO-Integration“. Ob der Dienstleister das in drei Tagen oder drei Wochen umsetzt, ist seine Sache.

Phase 3: Begleiten. Strategische Beratung auf Abruf, monatlich kündbar. Architekturreviews, Entscheidungsaudits, Frühwarnsystem für Fehlentwicklungen.

Ein zentrales Prinzip: Der Auftraggeber kann den Dienstleister jederzeit ersetzen. Jedes Dokument, jede Entscheidung, jeder Code gehört dem Auftraggeber. Bindung entsteht nur über Qualität, nicht über Abhängigkeit.

Was es nicht ist

Kein Wasserfall. Die fünf Modi wechseln sich in schneller Folge ab. Keine monatelange Planungsphase vor der Umsetzung.

Kein Alles-oder-Nichts. Teams können Decision-Driven Delivery schrittweise einführen. Ein guter Anfang: die Decision Map als ergänzendes Instrument neben dem bestehenden Backlog.

Kein Scrum-Feind. Teams können in der Umsetzung weiterhin Kanban, Pair Programming oder andere Methoden nutzen. Decision-Driven Delivery steuert, was gebaut wird und warum. Nicht wie.

Wie Sie anfangen können

Wenn Sie sich in den beschriebenen Problemen wiedererkennen, gibt es einen einfachen ersten Schritt: Schreiben Sie die fünf wichtigsten offenen Entscheidungen Ihres aktuellen Projekts auf. Nicht Aufgaben. Nicht Features. Entscheidungen.

Fragen Sie sich dann für jede: Wer ist zuständig? Welche Information fehlt, um sie zu treffen? Was blockiert, solange sie offen ist?

Wahrscheinlich werden Sie feststellen, dass mindestens eine dieser Entscheidungen seit Wochen offen ist, dass niemand klar zuständig ist, und dass das Projekt genau deshalb langsamer vorankommt als es sollte.

Das ist der Moment, in dem Decision-Driven Delivery beginnt.

Der D³ Guide führt Sie Schritt für Schritt durch das gesamte Framework — von Quick Start über Decision Records, Rollen, Rituale bis hin zu Metriken.