Wenn der Prozess funktioniert und das Produkt nicht
Ein Release, das vier Tage zu früh auslieferte und einundneunzig Prozent seiner zugesagten Ziele erreichte, ein Feature, das zweihundertelf Menschen nutzten gegenüber einer Prognose von vierzigtausend, und warum ein perfekt laufender Prozess einen mit voller Zuversicht in die falsche Richtung tragen kann.
Wir lieferten das Release vier Tage vor dem zugesagten Termin aus, und ich war damals stolz darauf.
Die Zahlen rund um dieses Release waren von der Art, die ein Programm haben möchte. Wir hatten in jenem Quartal einundneunzig Prozent unserer Program-Increment-Ziele erreicht, und unser Predictability-Maß war ein Jahr lang über achtzig Prozent geblieben. Jede System Demo war planmäßig gelaufen, jeder ART-Sync hatte stattgefunden, und der Inspect-and-Adapt-Workshop hatte eine ordentliche Liste von Verbesserungsmaßnahmen hervorgebracht, die verfolgt und abgeschlossen wurden. Nach jedem Maß, das die Methode uns lieferte, war das Programm bei guter Gesundheit. Das Feature, das wir über vier Program Increments gebaut hatten, wurde in seinem ersten Quartal im Feld von zweihundertelf Menschen genutzt. Der Business Case hatte vierzigtausend prognostiziert.
Der Abstand zwischen zweihundertelf und vierzigtausend ist das Thema dieses Essays. Dieser Abstand entstand nicht, weil in der Lieferung etwas schiefgelaufen wäre, denn die Lieferung war der Teil des Programms, der gelungen war. Wir hatten das gebaut, was wir uns vorgenommen hatten, nahe am versprochenen Zeitplan und in der definierten Qualität. Der Prozess tat alles, wofür er gemacht war, und das Produkt fand trotzdem fast niemanden.
Eine skalierte Methode wie SAFe ist ein Stated System von ungewöhnlicher Vollständigkeit. Sie sagt einem, wie man plant, wie oft man synchronisiert, wie man funktionierende Software demonstriert und wie man die eigene Leistung prüft und anpasst. Wenn eine Organisation die Methode gut betreibt, erzeugt sie einen steten Strom an Belegen dafür, dass sie die Methode gut betreibt, und all diese Belege sind echt. Ziele werden erreicht, Demos werden abgehalten, Abhängigkeiten werden sichtbar gemacht und gemanagt, und eine Predictability-Zahl entwickelt sich in eine beruhigende Richtung. Jeder Teil davon beantwortet eine Frage, nämlich ob wir der Methode so folgen, wie sie entworfen wurde. Nichts davon beantwortet die andere Frage, ob die Methode auf etwas zielt, das es wert ist, gebaut zu werden.
Die Lücke zwischen diesen beiden Fragen nenne ich den Drift, den Abstand zwischen dem System, das eine Organisation zu betreiben sagt, und dem System, in dem sie lebt. Meistens versteckt sich der Drift im Unterschied zwischen einem dokumentierten Prozess und einer weit unordentlicheren Wirklichkeit. Dies war die seltsamere Variante davon, in der der dokumentierte Prozess und die gelebte Wirklichkeit fast perfekt übereinstimmten und der Drift sich an einen viel schwerer sichtbaren Ort verlagert hatte, in den Zwischenraum zwischen einem Programm, das korrekt lief, und einem Programm, das das Richtige baute.
Zwei Arten von Grün
Einen Prozess gut zu betreiben schafft eine besondere Gefahr, nämlich dass die Gesundheit des Prozesses leicht zu lesen ist, während die Gesundheit des Produkts es nicht ist. Prozessgesundheit kommt jede Woche an, in Formaten, die so gestaltet sind, dass sie für jeden lesbar sind, der auf ein Board blickt. Produktwahrheit kommt Quartale später an, draußen im Feld, lange nachdem das Increment, das sie hervorbrachte, abgeschlossen und gefeiert wurde. Die beiden Signale laufen auf verschiedenen Uhren, und das schnellere, lautere ist das, das aus der Methode kommt.
Wenn die Kadenz grün ist, liest fast jeder sie als ein grünes Programm, einschließlich der Menschen, die senior genug sind, um den Unterschied kennen zu sollten. Ich las sie ein knappes Jahr lang so. Das Board erzählte mir jede Woche eine schlüssige und ermutigende Geschichte, und die Geschichte war wahr, so weit sie reichte. Was es mir nie sagen konnte, war irgendetwas über die vierzigtausend Menschen, die zu jenem Zeitpunkt eine Annahme in einer Tabelle waren und nicht jemand, mit dem wir gesprochen hatten.
Woher das Ziel kommt
Program-Increment-Ziele fühlen sich wie der Anfang der Arbeit an, obwohl sie näher an der Mitte liegen. Sie kommen bereits von einer Roadmap geformt, und die Roadmap kam bereits von einem Business Case geformt, den jemand lange schrieb, bevor irgendjemand von uns hätte wissen können, ob er Bestand haben würde. Die Zeremonien der Methode sind sehr gut darin, ein Ziel in funktionierende Software zu verwandeln. Keine einzige von ihnen ist dafür gebaut, zu fragen, ob das Ziel es überhaupt verdient hat zu existieren.
Es gibt in der Methode einen Platz für die Frage, ob wir das Richtige richtig gebaut haben, und die System Demo und die Definition of Done dienen ihm beide gut. Es gibt auch, auf dem Papier, einen Platz für die Frage, ob wir das Richtige bauen, der in dem Feedback liegt, das die System Demo sammeln soll, und in der Kundenbeteiligung, die das Framework empfiehlt. Dieser zweite Platz ist der erste, der übersprungen wird, wenn ein Programm beschäftigt ist, und ein gesundes Programm ist ohne Unterlass beschäftigt. Die Frage, die am dringendsten eine Antwort braucht, hat den schwächsten Halt im Kalender.
Ein vorhersagbares Programm ist eines, dessen Wirklichkeit mit seinem Plan übereinstimmte, und ein Plan kann vorhersagbar und mit voller Überzeugung falsch sein.
Das Jahr, in dem ich nicht fragte
Meine Rolle war es, die Trains am Laufen zu halten, und ich hielt sie gut am Laufen. Die Fragen, die ich in die Planung einbrachte, drehten sich um Kapazität, Reihenfolge, Abhängigkeiten und Risiko, und es waren gute Fragen. Jede von ihnen setzte voraus, dass die Ziele vor uns es wert waren, geliefert zu werden. Ich stand nie in einem Planungsevent auf und fragte, wer die vierzigtausend waren oder woher wir wussten, dass sie wollten, was wir gleich ein Jahr lang bauen würden. Diese Frage zu stellen gehörte zu keiner Rolle im Train, was hieß, nach der gewöhnlichen Logik von Organisationen, dass sie zu niemandem gehörte.
Das Feature wurde pünktlich und nach Spezifikation ausgeliefert. Die System Demos hatten stark ausgesehen, weil die Software tat, was die Stories beschrieben, die Stories taten, was die Features beschrieben, und die Features taten, was die Roadmap beschrieb. Jedes Glied dieser Kette war solide. Die Kette war am fernen Ende an eine Annahme über Nachfrage geschraubt, zu der niemand seit achtzehn Monaten zurückgekehrt war, und eine solide Kette, die an der falschen Wand verankert ist, trägt sehr viel Gewicht am falschen Ort.
Eine unserer Entwicklerinnen stellte mir spät im dritten Increment eine Frage, die ich nicht gut beantworten konnte. Sie sagte: Kennen wir irgendjemanden, der darauf wartet. Ich sagte: Es steht auf der Roadmap, und es hat im Review gut abgeschnitten. Sie sagte: Das ist nicht die Frage, die ich dir gestellt habe. Sie hatte recht, und ich wechselte das Thema, denn die ehrliche Antwort war, dass ich keine einzige Person kannte, die darauf wartete, und ich hatte das nie als Lücke in dem betrachtet, was ich wissen sollte.
Die Diagnose
Die Frage, die mich endlich ehrlich auf das Programm schauen ließ, war eine Zählung statt eines Urteils. Wie viele der Ziele, zu denen wir uns über die letzten vier Program Increments verpflichtet hatten, hatten sich verändert, weil wir etwas gelernt hatten, statt weil wir etwas geplant hatten? Ich ging die Aufzeichnungen durch und zählte sie richtig. Von achtunddreißig Zielen über vier Increments ließen sich siebenunddreißig in gerader Linie auf die Roadmap zurückführen, wie sie zu Jahresbeginn gestanden hatte. Genau eines hatte sich als Reaktion auf einen Beleg von einer echten Nutzerin verändert, und es hatte sich nur verändert, weil die Entwicklerin, die mir jene Frage gestellt hatte, sich die Mühe gemacht hatte, außerhalb jeder Zeremonie, jemandem dabei zuzusehen, wie er versuchte zu benutzen, was wir gemacht hatten.
Eine Rückkopplungsschleife, die in einem Jahr eine einzige Kurskorrektur hervorbringt, ist in keinem funktionierenden Sinn eine Rückkopplungsschleife. Sie ist eine Roadmap mit darum herum angeordneten Zeremonien, und die Zeremonien machten ihre Sache wunderbar. Sie verwandelten eine feste Menge von Annahmen in einem stetigen und vorhersagbaren Tempo in ausgelieferte Software. Die Predictability, auf die ich stolz gewesen war, war, in diesem Licht gelesen, ein Maß dafür, wie treu wir einen Plan ausgeführt hatten, den wir kein einziges Mal geprüft hatten.
Nimm die Ziele, zu denen sich dein Programm über seine letzten drei oder vier Increments verpflichtet hat, und sortiere sie in zwei Stapel. In den ersten die Ziele, die direkt von der Roadmap kamen, wie sie bereits stand. In den zweiten die Ziele, die existieren, weil das Programm etwas von einer Nutzerin, einer Kundin oder dem Feld gelernt hat, nachdem die Arbeit begonnen hatte. Zähle beide Stapel, bevor du einen von beiden verteidigst. Wo der zweite Stapel leer oder fast leer ist, trägt dich ein starker Prozess irgendwohin, das niemand geprüft hat, was eine angenehmere Lage ist als ein schwacher Prozess und eine erheblich schwerer zu bemerkende.
Was sich änderte, als ich anfing zu fragen
Was ich änderte, war klein, passend dazu, dass der Prozess keinen Neubau brauchte. Ich begann, die ersten fünfzehn Minuten eines Planungsevents pro Increment für eine einzige Frage zu reservieren, gestellt an die Menschen im Saal, bevor irgendein Ziel bestätigt wurde: Was haben wir seit dem letzten Mal gelernt, das ändern sollte, wozu wir uns gleich verpflichten. Für die ersten zwei Increments war die Antwort beinahe nichts, denn niemand hatte die Aufgabe bekommen, zwischen den Increments etwas zu lernen, und man kann keine Erkenntnisse berichten, für deren Erhebung man nie ausgestattet wurde.
Die Frage wurde immer wieder gestellt, Increment für Increment, und weil sie immer wieder gestellt wurde, zog sie langsam Antworten an. Menschen kamen mit kleinen Belegen, einem wiederkehrenden Support-Thema, etwas, das eine Kundin beiläufig gesagt hatte, einer Zahl aus dem Feld, die nicht zur Prognose passte. Die Ziele begannen, auf bescheidene Weise, sich zu dem hinzubiegen, was wir lernten. Unser Predictability-Maß sackte für ein paar Increments ab, während das geschah, und dieser Einbruch war das erste Mal, dass ich verstand, dass fallende Predictability ein Programm sein kann, das anfängt zuzuhören, statt ein Programm, das anfängt zu scheitern.
Die Methode war nie der Schurke dieser Geschichte, und sie herauszureißen hätte uns das eine gekostet, worin wir wirklich gut waren. Ein Prozess, der gut läuft, ist eine echte Leistung und wert, geschützt zu werden. Was ein Prozess nicht kann, so gut er auch läuft, ist einem zu sagen, ob das, was er baut, es verdient gebaut zu werden, und je besser er läuft, desto zuversichtlicher trägt er einen über den Punkt hinaus, an dem man hätte innehalten und nachsehen sollen. Das Grün, das bedeutet, die Methode ist gesund, und das Grün, das bedeutet, das Produkt ist gewünscht, sind zwei verschiedene Farben, und sie auseinanderhalten zu lernen ist der größte Teil der Arbeit.
Die Szenen in diesem Essay sind anonymisiert und, wo nötig, aus mehreren beruflichen Kontexten zusammengesetzt. Die Zahlen veranschaulichen das Muster, statt von einem einzelnen Team zu stammen. Sie sollen ein organisatorisches Muster beschreiben, keinen bestimmten Arbeitgeber, kein bestimmtes Programm und kein Team.
Der Abstand zwischen einem Prozess, der gut läuft, und einem Produkt, das es wert ist gebaut zu werden, ist ein Faden des Drift-Frameworks, des Rückgrats meines kommenden Buches Leading Agile When No One Agrees, das es über zweiundzwanzig Kapitel hinweg anhand von Szenen aus fünfzehn Jahren in agilen Transformationen durcharbeitet. Das Buch befindet sich in der finalen Vorbereitung für eine Veröffentlichung im Sommer 2026. Wenn dieser Text resoniert, sind die Begleitmaterialien in der Zwischenzeit vielleicht nützlich, angefangen beim Fünf-Fragen-Drift-Check. Wer lieber im Terminal arbeitet: drift-cli führt denselben Check lokal aus und sendet das Ergebnis nirgendwohin.
Mehr Texte und Updates zum Buchstart unter kylehauslaib.com.