Wie man das Delivery Board liest
Ein Steering-Deck, das neun von neun zugesagten Features grün zeigte, ein Programm, von dem jeder im Raum spürte, dass es ins Rutschen geriet, und die vier Lesungen desselben Boards, die mir endlich zeigten, wohin die Arbeit tatsächlich gegangen war.
Am Donnerstag der dritten Iteration zeigte das Steering-Deck neun von neun zugesagten Features grün, und jeder im Raum wusste, dass das Programm nicht grün war. Man konnte es daran spüren, wie die Architekten sprachen, an den Fragen, die einen Tick zu vorsichtig kamen, daran, dass immer dieselben zwei Namen fielen, wann immer tatsächlich etwas bewegt werden musste. Das Board log uns nicht an. Es beantwortete eine Frage, die keiner von uns beantwortet brauchte, nämlich ob die Punkte, die wir zu verfolgen vereinbart hatten, oberflächlich betrachtet im Plan lagen. Die Frage, die wir beantwortet brauchten, war, wohin die Arbeit gegangen war, und ein Status-Board ist so gebaut, dass man das nicht von ihm ablesen kann.
Ein Delivery Board ist Teil des Stated System: die Version des Programms, die auf einen Bildschirm passt, mit den Capabilities, den Features, den Storys, den Status und dem Burnup, der sich in die richtige Richtung biegt, wenn man die Augen zusammenkneift. Es ist wirklich nützlich, so wie eine Landkarte nützlich ist, und wie eine Landkarte lässt es alles weg, was das Gezeichnetwerden nicht überlebt hat. Das Lived System ist dort, wohin die Arbeit tatsächlich geht: der Punkt, der letzte Woche die Warteschlange übersprang, die Abhängigkeit von einem Team, das man nicht kontrolliert, das Feature, das in der Planung zugesagt wurde und sich seither nicht bewegt hat, der Architekt, der still vier Dinge über drei Trains hinweg zusammenhält. Der Abstand zwischen beiden ist das, was ich den Drift nenne, und ein Board, das nur auf seine Farbe gelesen wird, verbirgt den Drift von Natur aus, weil Farbe die eine Eigenschaft ist, die es ständig beruhigend halten soll.
Das Board ist die Frage, nicht die Antwort
Also habe ich aufgehört, ein Board zu lesen, um herauszufinden, ob es grün ist, und angefangen, es zu lesen, um herauszufinden, wovor das Grün mich abhalten soll. Das ist eine Haltung und keine Methode, also lass mich konkret werden. Es gibt vier Lesungen, die ich jetzt über jedes Delivery Board laufen lasse, bevor ich einem Wort seines Status traue, und jede ist eher eine Frage als eine Zahl. Keine davon ist schwer. Alle sind ein wenig unangenehm, was meist das Zeichen dafür ist, dass sie auf etwas Reales zielen.
Vier Lesungen
Die erste Lesung ist die Seitentür. Ich frage, wie viel der Kapazität vor mir hereinkam, ohne überhaupt durch die Planung zu gehen. Auf dem Programm, das ich beschreibe, waren es, als wir es endlich zählten, einunddreißig Prozent: ein regulatorischer Patch, den ein Lieferantenverzug dringend gemacht hatte, ein Demo-Build, um den eine Führungskraft direkt gebeten hatte, ein Re-Spin eines Steuergeräts, das niemand prognostiziert hatte. Nichts davon stand im zugesagten Plan, alles davon war echte Arbeit von echten Menschen, und jede Stunde davon war eine Stunde, die nicht für etwas aufgewendet wurde, das das Board immer noch grün zeigte. Seitentür-Arbeit ist keine Sünde. Sie ist Information. Das Ziel ist nie, die Tür zu schließen, denn die Tür ist aus einem Grund offen. Das Ziel ist zu sehen, was sie getragen hat, denn das ist die ehrlichste Schilderung, die du davon bekommst, was dem offiziellen Plan fehlte.
Die zweite Lesung sind die Grenzen. Ich frage, wo jedes Stück Arbeit von einem Team abhängt, das es nicht kontrolliert, und für jede dieser Abhängigkeiten, ob die Schnittstelle zwischen beiden tatsächlich vereinbart ist und ob sie jemandem gehört. Jahre mit sicherheitskritischer Software haben mich gelehrt, dass der gefährliche Teil eines Systems fast nie die Komponenten sind. Es ist die Grenze zwischen ihnen, der Ort, an dem zwei in sich korrekte Implementierungen sich um eine einzige Annahme unterscheiden, die niemand aufgeschrieben hat. Ein Backlog ist eine Liste von Implementierungen. Die Abhängigkeiten sind die Schnittstellen. Auf einem Board sind die Storys laut und die Abhängigkeiten eine dünne Linie, nach der man suchen muss, und die schlimmsten von ihnen, die, bei denen die Schnittstelle keine vereinbarte Form und keinen Eigentümer hat, sind genau die, die in keinem Status auftauchen, bis zu der Iteration, in der sie hochgehen.
Die dritte Lesung ist der Drift zwischen zugesagt und aktiv. Ich lege das, was in der Planung vereinbart wurde, neben das, woran jetzt tatsächlich gearbeitet wird, und ich betrachte die Lücke in beide Richtungen. Es gibt zugesagte Arbeit, die sich seit zwei Iterationen nicht bewegt hat, grün dasitzend, weil nichts einen stehengebliebenen Punkt von selbst rot werden lässt. Und es gibt aktive Arbeit, die niemand geplant hat, was wieder die Seitentür ist, von der anderen Seite gesehen. Das Zugesagt-und-Stehengebliebene und das Aktiv-und-Ungeplante sind zwei Hälften desselben Drifts, und ein Board, das dir nur die zugesagten Punkte zeigt, oder nur die aktiven, lässt dich weiter glauben, der Plan und die Realität seien dasselbe Dokument.
Die vierte Lesung ist die Kapazität, womit ich meine, wo die Menschen tatsächlich sind, statt wie viele von ihnen es zufällig gibt. Ich suche die Person, die auf den meisten Punkten erscheint, und ich frage, was bricht, wenn sie eine Woche weg ist. Auf jenem Programm war es ein leitender Architekt, der sechs aktive Punkte über vier Trains trug, was das Board als sechs gesunde Zuweisungen verzeichnete und was tatsächlich ein Single Point of Failure mit einem Kalender war. Ich suche das zugesagte Feature, an dem niemand sitzt, die Arbeit, die in jemandes Kopf lebt statt auf dem Board. Und ich suche die sicherheitsrelevante Story mit genau einem Namen daneben, denn ein Bus-Faktor von eins auf dem Teil, der jemandem wehtun kann, ist die Art von Risiko, die unsichtbar bleibt, bis sie das Einzige ist, worüber alle reden.
Ein Status-Board ist dafür gebaut, grün zu bleiben, während das Programm ins Rutschen gerät. Die vier Lesungen sind die Fragen, die das Rutschen sichtbar machen.
Wer für die Lücke bezahlt
Die Lesungen sind nur die Hälfte. Die Frage, die sie von einer interessanten Prüfung in eine Entscheidung verwandelt, ist die, die ich über jede Lücke, die ich finde, offen zu halten versuche, nämlich wer für sie bezahlt. Seitentür-Arbeit wird von dem bezahlt, was sie verdrängt hat, meist dem zugesagten Feature, das immer noch grün zeigt, weil niemand seine Farbe änderte, als seine Leute still abwanderten. Eine Schnittstellenlücke wird bei der Integration bezahlt, von dem Team, das stromabwärts ist, wenn die beiden Annahmen endlich aufeinandertreffen. Stehengebliebene zugesagte Arbeit wird von allen bezahlt, die immer noch um ein Ding herum planen, das nicht passiert. Und ein überlasteter Architekt wird irgendwann vom Architekten bezahlt, und dann von allen, die von den sechs Dingen gleichzeitig abhingen. Eine Lücke, an deren Kosten kein Name hängt, ist keine Lücke, die jemand zu behalten beschlossen hat. Sie ist nur eine, die noch niemand gelesen hat.
Die Diagnose
Nimm dein aktuelles Board, das echte, auf dem dein Programm läuft. Frage nicht, ob es grün ist. Frage stattdessen vier Zählungen, und schreibe sie auf, bevor du auf den Status schaust. Welcher Anteil der Kapazität vor dir kam außerhalb der Planung herein. Wie viele teamübergreifende Abhängigkeiten haben keine vereinbarte Schnittstelle und keinen Eigentümer. Wie viele zugesagte Punkte haben sich seit zwei Iterationen nicht bewegt. Und welche einzelne Person erscheint auf den meisten Punkten, und was bricht, wenn sie eine Woche weg ist. Der Status wird dir sagen, dass das Programm in Ordnung ist. Die vier Zahlen werden dir sagen, in welche Richtung es geht, und die Lücke zwischen den beiden Lesungen ist genau das, wofür deine Rolle eigentlich existiert.
Ich habe genug Zeit damit verbracht, Boards zu beschreiben, dass es sich lohnte, eines zu bauen, das man tatsächlich auf diese Weise lesen kann, also tat ich es. Der E/E Solution Tracker ist ein interaktives Live-Board für ein fiktives Automotive-Programm, mit den vier Lesungen als vier Linsen eingebaut, zwischen denen du wechseln kannst: Seitentür, Grenzen, Drift und Kapazität. Du kannst zusehen, wie dasselbe Programm unter einer Lesung in Ordnung und unter einer anderen alarmierend aussieht, einen Regler ziehen, um zu wiederholen, wie sich der Drift über das Increment hinweg ansammelte, während der Top-Line-Status beruhigend grün blieb, und, wenn du lieber möchtest, einen Export deines eigenen Boards einwerfen und es auf dieselbe Weise lesen. Es ist das Framework aus diesem Essay, gemacht zu etwas, das du mit den Händen bewegen kannst.
Das Programm in diesem Essay ist anonymisiert und aus mehr als einem Kontext zusammengesetzt, und die Zahlen veranschaulichen das Muster, statt aus einem einzelnen Team zu stammen. Es soll ein organisatorisches Muster beschreiben, keinen bestimmten Arbeitgeber, kein Programm und kein Team. Die Ansichten sind meine eigenen.
Den Abstand zwischen dem Board und der Arbeit zu lesen 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 einer Laufbahn in Engineering-Organisationen 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, insbesondere das Seitentür-Audit und der Fünf-Fragen-Drift-Check. Wer lieber im Terminal arbeitet: drift-cli führt denselben Fünf-Fragen-Check lokal aus und sendet das Ergebnis nirgendwohin. Ein Wert, der nach oben berichtet wird, hört auf, die Lücke zu messen, und fängt an, sie zu erzeugen, deshalb behält das Tool ihn bewusst auf deinem Rechner.
Mehr Texte und Updates zum Buchstart unter kylehauslaib.com.