Schrödingers Roadmap

[🇬🇧 - Schrödinger’s Roadmap]

🚦 Schrödingers Roadmap: Ein Status-Nicht-Report↑

Mittwochnachmittag bei FluxIon Grid. Dennis hat die achtzehnmonatige Roadmap fertiggestellt. Elf Teams. Vierundsechzig Epics. Dreiundsiebzig farbige Balken, die feinsäuberlich im ersten Quartal 2028 terminieren.

Das PDF wurde am Freitag aus dem Portfolio-Tool exportiert. Am Montag teilt Sarah ihm beiläufig mit, dass die Migration der Settlement-Schicht sieben zusätzliche Wochen benötigen wird. Dennis trägt diese Verzögerung nicht in die Roadmap ein. Würde er Zeile 31 verschieben, würde das eine Kaskade durch jede nachgelagerte Abhängigkeit auslösen und visuell unwiderlegbar beweisen, dass das gesamte Dokument bereits jetzt obsolet ist.

Also färbt er den Balken in einem minimal helleren Grünton ein und tippt „in Klärung“ in das Kommentarfeld.

Die Vorstandsmitglieder, die das Diagramm um 11:00 Uhr im Lenkungsausschuss begutachten, lesen keine Kommentarfelder. Das ist die Roadmap-Illusion in ihrer reinsten Form: Ein Plan, der gleichzeitig grün und absolut nicht grün ist. Kein Mensch an diesem Tisch glaubt ernsthaft an den Go-Live der „Smart-Settlement v3“ im Februar 2027. Aber niemand wird das laut aussprechen. Die Folie wird durchgewunken, um zwölf Uhr kommt das Catering, und der dritte Donnerstag im Februar 2027 wird gerissen, ohne irgendjemanden zu überraschen.

Dennis legt das unterschriebene PDF im Reiter Portfolio Q4 2026 als grünes Item ab. Dipl.-Ing. Lehmann hakt das Kästchen ab. Schrödingers Roadmap hat ihren wahren Job erledigt, lange bevor der erste Balken gezeichnet wurde: Sie hat die Panik der Geschäftsführung vor der Ungewissheit erfolgreich in die Illusion von Kontrolle verwandelt.

📐 Der Trichter der Ungewissheit: Warum ein Datum bei Projektstart nur ein frommer Wunsch ist↑

Barry Boehm hat 1981 in Software Engineering Economics die natürliche Varianz von Aufwandsschätzungen gemessen. Der Datensatz, über den er seinen berühmten Trichter legte, war kein theoretisches Gedankenexperiment. Es war die nackte Lieferrealität dutzender militärischer Softwareverträge, abgeglichen mit ihren ursprünglichen Schätzungen an vier definierten Meilensteinen: Machbarkeit, Anforderungsdefinition, Design und Code-Complete.

Das Ergebnis auf Seite 311: Genau beim Start eines nichttrivialen Softwareprojekts, wenn die Anforderungen noch verschwommen sind und die Architektur nicht steht, weisen Schätzungen eine Streuung um den Faktor vier in beide Richtungen auf.

Ein Feature, das auf zehn Wochen geschätzt wird, könnte in zweieinhalb Wochen fertig sein. Oder in vierzig.

Der Mittelwert dieser Spanne hat exakt null operative Bedeutung, weil die Verteilung asymmetrisch ist. Software-Schätzungen haben eine harte Grenze nach unten (du kannst Code nicht in negativer Zeit ausliefern), sind aber nach oben völlig offen (du kannst beliebig spät dran sein). Der Mechanismus, den Boehm hier benennt, ist struktureller Informationsmangel. Beim Projektstart sind die Variablen, die die tatsächlichen Kosten treiben, schlichtweg unbekannt. Architektur, Integrationsaufwand, regulatorische Reibung, neu entdeckte Defekte.

Diese Dinge werden nicht schlecht geschätzt. Sie sind zu diesem Zeitpunkt einfach noch nicht sichtbar.

Der Trichter verengt sich erst, während das Projekt fortschreitet. Sobald die Architektur steht, schrumpft die Streuung auf den Faktor zwei. Sobald der erste vertikale Schnitt in Produktion ist, landet die Genauigkeit bei plus-minus 25 Prozent. Drei Wochen vor der Auslieferung ist das Datum auf die Woche genau vorhersagbar. Der Trichter verengt sich strukturell, und zwar nicht, weil die Schätzenden plötzliche Erleuchtung finden, sondern weil die Informationslage dichter wird.

Eine achtzehnmonatige Roadmap zwingt das Team zu einer harten Verpflichtung am breitesten Ende dieses Trichters. Es ist der Moment der maximalen Varianz, der per Vorstandsbeschluss zum Moment der maximalen Gewissheit deklariert wird.

🧠 Die Inside-View-Falle: Warum deine Senior-Architekten schätzen wie Hochschulabsolventen↑

Daniel Kahneman und Amos Tversky lieferten 1979 die kognitive Erklärung dafür. Der Planungsfehlschluss (Planning Fallacy) ist die systematische menschliche Tendenz, den Zeit- und Arbeitsaufwand für zukünftige Vorhaben massiv zu unterschätzen, selbst wenn die schätzende Person sich problemlos an vergleichbare vergangene Projekte erinnern kann.

Auf die Frage „Wann wird das fertig sein?“ konstruiert das Gehirn sofort einen idealisierten Filmablauf: saubere Anforderungen, grüne Tests, ein durchwinkendes Compliance-Gate. Die Schätzung ankert exakt auf diesem internen Traum-Szenario. Die Erinnerung an die letzten fünf Projekte, in denen allein das Security-Review elf Wochen verschlungen hat, wird schlichtweg nicht abgerufen.

Kahneman nannte das den Inside View. Das Gegenmittel, der Outside View, erfordert das brutale Ignorieren der spezifischen Details des aktuellen Projekts und stattdessen eine Prognose basierend auf der historischen Verteilung vergleichbarer vergangener Projekte. Das wird in der Konzernrealität fast nie gemacht, weil es sich für das Management wie Defätismus anfühlt.

Magnus Jørgensen hat 2004 dutzende empirische Studien zur menschlichen Aufwandsschätzung in der Softwareentwicklung ausgewertet. Das konsolidierte Ergebnis: Experten unterschätzen den Aufwand systematisch um dreißig bis fünfzig Prozent. Und diese Verzerrung nimmt mit wachsender Erfahrung nicht messbar ab.

Ein Senior-Architekt mit zwanzig Jahren tiefem Domänenwissen produziert bei der Schätzung exakt dieselbe systematische Verzerrung wie eine frische Hochschulabsolventin in ihrem ersten Projekt.

Nur die absolute Streubreite wird etwas kleiner. Seniorität kauft dich nicht aus dem Inside View frei. Sie sorgt nur für ein besseres Gehalt während der Verzögerung.

📉 Die Multiplikations-Falle: Wie aus 40 Prozent Abweichung ein Lottogewinn wird↑

Die Roadmap, die der Vorstand am Ende feierlich unterschreibt, besteht aus lauter Einzelposten, von denen jeder im Durchschnitt vierzig Prozent zu früh geschätzt wurde. Diese Posten sind in einem Abhängigkeitsgraphen verkettet. Und dieser Graph mittelt die Verzerrung nicht etwa heraus, sondern multipliziert sie.

Sam Savage hat die Mathematik dazu in The Flaw of Averages durchgerechnet. Nimm zehn Aufgaben, die hintereinander verkettet sind, von denen jede einzelne eine fünfzigprozentige Wahrscheinlichkeit hat, pünktlich nach Plan zu laufen. Die gesamte Kette hat am Ende eine Wahrscheinlichkeit von exakt 1 zu 1.024, pünktlich abgeschlossen zu werden. In Serie geschaltete Mittelwertschätzungen produzieren eine Lieferwahrscheinlichkeit, die sich in Luft auflöst, lange bevor das im Lenkungsausschuss politisch zugegeben wird.

Schau dir Dennis’ Diagramm noch einmal an. Vierundsechzig Epics. Teamübergreifende Abhängigkeiten bei jedem zweiten Item. Die Wahrscheinlichkeit, dass dieses Diagramm so eintrifft, wie es dort farbig gezeichnet ist, unterscheidet sich strukturell nicht von null. Der Vorstand muss nicht zwingend schlecht in Mathematik sein, um das zu übersehen. Er muss sich nur angewöhnen, immer nur einen Balken gleichzeitig zu betrachten.

🚧 Die Pünktlichkeits-Fata-Morgana: Wo deine Terminüberschreitung wirklich versteckt wurde↑

Der natürliche Einwand aus dem Lenkungsausschuss lautet an dieser Stelle sofort, dass manche Programme ihre Termine ja durchaus halten. Das tun sie, und die Analyse dieser Erfolge ist extrem lehrreich. Programme, die ihre magischen Daten treffen, fallen ausnahmslos in eines von drei erkennbaren Mustern:

• Das Programm war in der Realität klein und perfekt verstanden. Der Trichter der Ungewissheit war von Beginn an extrem schmal. Das Datum zu treffen war keine außergewöhnliche Management-Fähigkeit. Es war schlicht die Abwesenheit von Varianz.
• Das Team hat den Umfang zusammengestrichen, bis das Datum gehalten hat. Die Hälfte der ursprünglich versprochenen Features ist leise in das nächste Quartal verschwunden. Das Datum steht. Aber die Definition von „Fertig“ wurde radikal umgeschrieben.
• Das Team hat in den finalen Wochen Feuerwehr-Kultur und Überstunden geliefert, die auf keinem Plan standen. Das Datum hat gehalten. Die echten Kosten tauchen dann sechs Monate später in der Burn-out-Quote, in der Kündigung der Lead-Architektin mit dem Bus-Faktor 1 und in der explodierenden Bug-Rate des liefernden Teams auf.

Nichts davon widerlegt die Mathematik. In jedem dieser Fälle hat das System die Variable „Datum“ nur deshalb konstant halten können, weil es heimlich eine andere Variable angepasst hat: Scope, Qualität oder die physische Gesundheit der Menschen. Was sich zwischen den Programmen ändert, ist nicht die Frage, ob die Physik gilt. Es ändert sich nur, welche Variable die unausweichliche Verzögerung absorbiert.

Schrödingers Roadmap verbirgt lediglich, welche es diesmal war.

📊 Das Konfidenzband: Ersetze den einzelnen Balken durch eine Wahrscheinlichkeit↑

Dan Vacanti hat die Alternative 2015 in Actionable Agile Metrics for Predictability operationalisiert. Der Datensatz, auf dem Vacanti seine Methode aufbaute, war nicht theoretisch modelliert. Es war der nackte, tatsächliche Ticket-Durchsatz von dutzenden Delivery-Teams aus dem Finanzsektor, der Telekommunikation und dem E-Commerce, gemessen in wöchentlichen Blöcken über zwölf bis vierundzwanzig Monate hinweg.

Der Mechanismus: Anstatt Menschen zu fragen „Wann werden diese vierzig Tickets fertig sein?“, nimmst du die historische Durchsatz-Verteilung deines Teams (abgeschlossene Tickets pro Woche über die letzten zehn bis zwanzig Wochen) und ziehst aus dieser Verteilung mittels einer Monte-Carlo-Simulation zehntausend mögliche Zukünfte.

Das Ergebnis ist kein fiktives Datum. Es ist eine harte Wahrscheinlichkeitsverteilung: 50 Prozent Konfidenz bis Woche elf, 85 Prozent bis Woche vierzehn, 95 Prozent bis Woche siebzehn.

Der kognitive Fehler, den diese Technik komplett entschärft, ist der Inside View. Niemand muss mehr raten, wie lange irgendetwas dauern wird. Das Team schaut sich an, wie lange Dinge in der Realität tatsächlich gedauert haben, und überlässt die Verkettung der Simulation. Die Multiplikations-Falle verpufft, weil Monte Carlo die Varianz mathematisch korrekt abbildet. Der Planungsfehlschluss verschwindet, weil sich hier kein Mensch die Zukunft zurechthalluziniert, sondern historischen Daten sie vorhersagen.

Für Dennis bedeutet das: Die Linie Smart-Settlement v3 auf der Vorstandsfolie trägt nicht länger den Text „GO LIVE 18. Februar 2027“. Sie trägt stattdessen den Text „50% Konfidenz Q1 2027, 85% Q2 2027, 95% Q3 2027“. Gleiches Team, gleiches Backlog, gleicher Montagmorgen. Völlig anderes Format.

Die Mathematik dahinter ist relativ simpel. Die eiserne Disziplin, den Durchsatz absolut ehrlich zu messen, ist es nicht. Die meisten Organisationen können diese Simulation nicht fahren, weil ihre Jira-Daten massiv kontaminiert sind: Durch blockierte Tickets, die lautlos neu geschätzt werden, um individuelle Sprints künstlich grün zu halten. Durch Epics, deren Größe durch politische Verhandlungen statt durch echtes Slicing bestimmt wird. Und durch eine Definition of Done, die je nach Team und Quartal fröhlich variiert. Wer basierend auf Durchsatz prognostizieren will, braucht zwingend zuerst ehrliche Durchsatz-Daten.

Der Lenkungsausschuss wird das neue Format beim ersten Kontakt hassen. Der einzelne Balken war ein gefühlter Vertrag; das Band ist ein offenes Eingeständnis von Unsicherheit. Sie werden den Wert des Bandes erst an dem Tag schätzen lernen, an dem der frühe Rand der Wahrscheinlichkeit eintrifft und ein Erfolg verbucht werden kann, den das alte Format gnadenlos als Fehler markiert hätte.

🌊 Die rollierende Welle: Warum nur kontinuierliche Auslieferung eine ehrliche Prognose erlaubt↑

Um überhaupt an werthaltige Daten zu kommen, auf denen die Monte-Carlo-Simulation operieren kann, braucht es zwei strukturelle Hebel, die den Trichter der Ungewissheit verengen, noch bevor die Simulation startet.

Der erste Hebel ist die Batch-Größe. Don Reinertsen hat in The Principles of Product Development Flow gezeigt, dass Varianz nicht linear mit dem Planungshorizont wächst. Ein sechsmonatiges Commitment trägt exakt sechs Monate akkumulierte Unbekannte in sich. Ein sechswöchiges Commitment trägt sechs Wochen. Der absolute Durchsatz des Teams bleibt identisch; die Vorhersagbarkeit ändert sich dramatisch.

Rollierende Planung (Rolling-Wave Planning), bei der ausschließlich das nächste Quartal als verbindlich gilt und alle folgenden Quartale nur noch grobe Richtung vorgeben, ist das ehrliche Eingeständnis, dass sich der Trichter erst bei direkter Annäherung verengt. Das nächste Quartal sitzt im schmalen Teil des Trichters. Das übernächste tut es nicht.

Der zweite Hebel ist die Release-Architektur. Jez Humble und Dave Farley argumentieren in Continuous Delivery, dass das technische Deployment von Code rigoros von seiner funktionalen Aktivierung für den Kunden getrennt werden sollte. Code wandert kontinuierlich in Produktion, geschützt durch Feature Flags. Die funktionale Aktivierung ist dann lediglich eine Konfigurationsänderung, kein Deployment.

Die gewaltige Varianz, die deine Roadmap bisher zerrissen hat, fällt in sich zusammen. Denn das Commitment bezieht sich jetzt auf ein Ereignis mit extrem niedriger Varianz (einen Schalter umlegen), anstatt auf ein Ereignis mit extrem hoher Varianz (integrieren, stundenlange Regressionstests fahren, und hoffen, dass das System an einem Dienstagabend nicht abraucht).

Ein Jahrzehnt DORA-Forschung belegt die direkte Konsequenz: Teams, die On-Demand deployen, haben eine Change Lead Time von unter einem Tag. Teams, die ihre Arbeit in quartalsweisen Releases bündeln, brauchen für exakt dieselbe Änderung einen bis sechs Monate. Die Roadmap-Varianz ist eine Eigenschaft deiner Release-Architektur, nicht deiner Arbeit. Wenn deine Gantt-Balken achtzehn Monate lang sind, ist deine Release-Architektur der Grund dafür. Die Arbeit an sich erfordert das nicht.

Für die Praxis ändern sich am nächsten Montag genau zwei Artefakte:

• Das Portfolio-Review akzeptiert kein Commitment mehr als verbindlich, das über das nächste Quartal hinausgeht. Balken dahinter werden farblich strikt als Richtung markiert, nicht als hartes Datum.
• Der Release-Kalender wird vollständig vom Deployment-Kalender entkoppelt. Das Marketing bucht ein Aktivierungsdatum. Das Engineering shippt den Code kontinuierlich Wochen vorher in Produktion, sicher hinter einem Flag.

🪑 Die Asymmetrie der Unterschrift: Wer das Datum absegnet und wer es ausliefern muss↑

Die Roadmap als ratifiziertes Dokument ist primär ein Macht-Artefakt. Die Unterschrift unten auf der Folie gehört dem Vorstand. Die Wahrscheinlichkeit, dieses Datum in der Realität zu treffen, gehört einem Team drei Hierarchieebenen tiefer, dessen tatsächliche Durchsatz-Daten der Vorstand noch nie im Leben gesehen hat. Der Raum, der die formale Autorität besitzt, das Datum zu fixieren, ist strukturell komplett isoliert von dem Raum, der die Informationen darüber besitzt, ob dieses Datum physikalisch überhaupt machbar ist.

Lies diese Konfiguration in der Sprache der Vier Rollen, Fünf Mächte: HR-Legitimate-Autorität und der disziplinarische Vertrag sitzen am Vorstandstisch. Architecture-Legitimate-Autorität und die empirischen Durchsatz-Daten sitzen drunten beim Team.

Genau dazwischen steht ein Proxy-PO, dessen einziges Mandat die Pflege der Roadmap ist und dessen eigene Jahresbewertung massiv davon abhängt, dass diese Roadmap im Lenkungsausschuss gemanagt aussieht. Dennis lügt nicht absichtlich, wenn er den Balken in einem helleren Grün einfärbt. Er optimiert lediglich hart auf die einzige Metrik, für die seine Rolle existiert.

Diese Informationsasymmetrie ist strukturell, nicht persönlich. Der Vorstand sieht eine einzige Zahl pro Epic pro Quartal. Das Team sieht die historische Durchsatz-Verteilung Woche für Woche. Schrödingers Roadmap ist das Artefakt, das die Realität der zweiten Ansicht gnadenlos in die Illusion der ersten Ansicht konvertiert und dabei jede störende Varianz unter den Teppich kehrt. Den einzelnen Balken durch ein Konfidenzband zu ersetzen, ist daher keine banale Prognose-Reform, sondern eine kleine Umverteilung von Entscheidungsrechten: Der Vorstand bekommt ein etwas hässlicheres Diagramm, aber dafür ein mathematisch sauberes Commitment.

Dieser Tausch ist die eigentliche Führungsarbeit. Die Monte-Carlo-Mathematik ist der einfache Teil.

⚠️ Die Anker-Migration: Wenn das 85. Perzentil plötzlich zur neuen Deadline mutiert↑

Probabilistisches Forecasting hat einen extrem vorhersehbaren Failure Mode, und du solltest ihn laut benennen, bevor der Lenkungsausschuss ihn ganz von alleine entdeckt.

Dieser Failure Mode ist die Anker-Migration. Im ersten Quartal mit den neuen Konfidenzbändern liest der Vorstand 50 Prozent / 85 Prozent / 95 Prozent und behandelt sie tatsächlich als das, was sie sind: Wahrscheinlichkeiten. Spätestens im dritten Quartal stellt irgendjemand im Raum die unausweichliche Frage: „Welche dieser drei Zahlen ist denn nun das verbindliche Commitment?“ Das Team, unter massivem Druck, antwortet mit dem 85. Perzentil. Und exakt ab diesem Quartal mutiert das 85. Perzentil zu einer knallharten Deadline. Die 50 Prozent verschwinden stillschweigend von der Folie. Die 95 Prozent werden zu einem Puffer degradiert, der im Kopf des Managements ohnehin schon längst ausgegeben ist.

Der Planungsfehlschluss ist einfach nur eine Abstraktionsebene nach oben migriert. Der einzelne Balken ist zurück. Nur das Etikett hat sich geändert.

Die einzige strukturelle Verteidigung besteht darin, jeden. einzelnen. Monat. alle drei Bänder auf der Folie zu belassen. Du musst das Team für die Form seiner Durchsatz-Verteilung verantwortlich machen, nicht für das exakte Treffen des 85. Perzentils. Und als Agile Coach musst du dich rigoros weigern, das Format jemals wieder auf eine einzige Zahl kollabieren zu lassen. Diese Verteidigung ist härter, als das Python-Skript für die Simulation zu schreiben. Die Simulation ist Mechanik. Die Disziplin, Ungewissheit Quartal für Quartal brutal sichtbar zu lassen, ist echte Governance.

Vacantis Hebel greift sicher. Man kann diesen Hebel aber auch am falschen Ende greifen. Zwei Aussagen können gleichzeitig wahr sein.

🏁 Fazit: Ein Plan ist eine Verteilung, kein Datum auf dem Kalender↑

Der tiefere strukturelle Fix ist Beyond Budgeting im Sinne von Bjarte Bogsnes: die radikale Entkopplung von Zielsetzung, Prognose und Ressourcenallokation, anstatt alles in das starre Jahresbudget zu pressen. Das ist ein mehrjähriger CFO-Move, den die meisten Engineering-Organisationen nicht im Alleingang zünden können.

Was eine Engineering-Organisation aber bereits am nächsten Montag selbst tun kann:

• Ersetze das einzelne Datum durch ein Konfidenzband, das direkt aus dem tatsächlichen Durchsatz des Teams gespeist wird. Keine Fantasie, kein Inside View.
• Mache ausschließlich das nächste Quartal verbindlich. Behandle alles danach als grobe Richtung.
• Entkopple das Deployment radikal vom Release durch Feature Flags. Verschiebe das hochvariable Ereignis weg von dem Kalender, den der Vorstand liest.
• Lass alle drei Bänder in jedem Quartal sichtbar. In dem Moment, in dem die Folie auf eine einzige Zahl kollabiert, hast du die Mathematik wieder beerdigt.

Schrödingers Roadmap überlebt in Konzernen so hartnäckig, weil sie dem Vorstand das warme Gefühl von Kontrolle gibt, ohne dass irgendjemand jemals in die unschönen Daten darunter schauen muss. Das Konfidenzband macht die Daten selbst zum Artefakt. Das ist für alle Beteiligten hochgradig ungemütlich. Was ein anderes Wort für ehrlich ist.

Boehm publizierte 1981. Kahneman publizierte 1979. Vacanti publizierte 2015. Nichts davon ist eine Neuigkeit. Die Tatsache, dass es in deinem Lenkungsausschuss immer noch als radikale News gilt, ist die eigentliche Diagnose.

⏱️ TL;DR: Die 60-Sekunden-Realität↑

Für das C-Level, das genau sechs Minuten zwischen zwei Lenkungsausschüssen hat:

• Die Roadmap wird bei maximaler Ahnungslosigkeit unterschrieben: Boehms Trichter zeigt bei Projektstart eine Streuung um den Faktor vier. Ein 18-monatiges Datum ist mathematisch gesehen ein frommer Wunsch, an den jemand ein Kalender-Tag geklebt hat.
• Seniorität heilt den Inside View nicht: Jørgensens Auswertung beweist: Dreißig bis fünfzig Prozent systematische Unterschätzung, völlig unabhängig von der Erfahrung der Architektin. Die Verzerrung ist strukturell, kein Kompetenzproblem.
• Mittelwerte multiplizieren sich, sie gleichen sich nicht aus: Zehn verkettete 50-Prozent-Schritte landen bei einer Wahrscheinlichkeit von eins zu tausend. Dein 64-Epics-Gantt-Chart hat eine strukturelle Wahrscheinlichkeit von null, jemals so einzutreffen.
• Pünktliche Programme sind klein, beschnitten oder bezahlt mit Burn-out: Die Variable, die deine Verzögerung absorbiert, ist einfach nur irgendwo abseits des Diagramms versteckt worden.
• Ersetze den Balken durch ein Konfidenzband: Nutze Monte-Carlo-Simulationen basierend auf echtem Ticket-Durchsatz. Drei Wahrscheinlichkeiten pro Epic, kein fiktives Datum.
• Verkürze den Horizont und entkopple Deployment vom Release: Mache nur das nächste Quartal verbindlich. Liefere Code kontinuierlich hinter Feature Flags aus. Das Marketing wählt das Aktivierungsdatum, das Engineering bestimmt das Deployment.
• Verhindere die Anker-Migration: Lass nicht zu, dass das 85. Perzentil zur neuen Deadline mutiert. Behalte alle Bänder sichtbar, sonst schleicht sich der Planungsfehlschluss einfach eine Ebene höher wieder ein.

🧾 Die Belege: Die Mathematik und die Historie↑

Wenn dein Lenkungsausschuss hartnäckig darauf pocht, dass das 18-monatige Gantt-Chart ein verbindlicher Vertrag ist, leg ihnen diese Quellen auf den Tisch.

• Boehm, B. (1981). Software Engineering Economics (ISBN 978-0138221225). Die originalen Daten zum Trichter der Ungewissheit, basierend auf realen TRW-Verträgen an vier definierten Meilensteinen. Der mathematische Beweis, dass Varianz strukturell durch Informationen schrumpft, nicht durch besseres Schätzen.
• Bossavit, L. (2015). The Leprechauns of Software Engineering (ISBN 978-2954745503). Die kritische Neuüberprüfung der populären Trichter-Zahlen. Extrem nützlich als Kalibrierungs-Check, bevor du Boehm in einem feindseligen Raum zitierst.
• Kahneman, D., & Tversky, A. (1979). „Intuitive Prediction: Biases and Corrective Procedures.“ TIMS Studies in Management Sciences, 12, 313–327. Das originale Paper zum Planungsfehlschluss. Hier lebt die entscheidende Unterscheidung zwischen Inside View und Outside View.
• Kahneman, D. (2011). Thinking, Fast and Slow (ISBN 978-0374533557). Die populäre Synthese. Das Kapitel zum Inside View ist genau das, was du dem Vorstand vorlegen solltest.
• Jørgensen, M. (2004). „A review of studies on expert estimation of software development effort.“ Journal of Systems and Software, 70(1–2), 37–60. Der empirische Beweis, dass 30 bis 50 Prozent Unterschätzung völlig unabhängig von der Seniorität sind. Der Grund, warum „wir lassen das unsere fähigste Architektin schätzen“ absolut keine taugliche Verteidigung ist.
• Savage, S. L. (2009). The Flaw of Averages (ISBN 978-1118073759). Die Mathematik der Mittelwert-Verkettung. Der Grund, warum ein Gantt-Chart mit 64 Epics definitiv kein Münzwurf ist.
• Vacanti, D. S. (2015). Actionable Agile Metrics for Predictability (ISBN 978-0986436338). Die oben beschriebene Durchsatz-basierte Prognosemethode, von vorn bis hinten, mit durchgerechneten Monte-Carlo-Beispielen. Die wichtigste Referenz für Praktiker, die diesen Hebel nutzen wollen.
• Reinertsen, D. G. (2009). The Principles of Product Development Flow (ISBN 978-1935401001). Das Argument zur nicht-linearen Varianz bei steigender Losgröße. Die strukturelle Rechtfertigung dafür, warum maximal das nächste Quartal verbindlich zugesagt werden darf.
• Humble, J., & Farley, D. (2010). Continuous Delivery (ISBN 978-0321601919). Das originale Buch zur Entkopplung von Deployment und Release. Der Grund, warum das hochvariable Ereignis nichts auf dem Kalender des Vorstands zu suchen hat.
• Bogsnes, B. (2016). Implementing Beyond Budgeting, 2. Aufl. (ISBN 978-1119152477). Die strukturelle Wurzel der jährlichen Roadmap. Die Reform, die eine Engineering-Organisation zwar nicht selbst zünden, aber zumindest beim Namen nennen sollte.
• Google Cloud (2024). Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/. Die longitudinalen Beweise dafür, dass die Change Lead Time eine Eigenschaft der Release-Architektur ist, nicht der Arbeit selbst.