Abends ziehe ich ein paar Dokumente auf dem Board in die richtige Spalte, vergebe ein Label und gehe schlafen. Morgens lese ich das Protokoll. Das ist seit Monaten mein Rhythmus, und bis vor kurzem betraf er nur die Implementierung.

Jetzt gibt es drei Modi, in denen mein Nacht-Runner läuft, und der dritte ist der, über den ich schreiben will.

Modus eins, die Implementierung

Der Runner arbeitet die Ready-Spalte ab, ein Arbeitspaket nach dem anderen, und startet für jedes eine frische Session. Wenn eine Session zehn Issues hintereinander bearbeitet, sammelt sich Kontext an, und die Qualität sinkt schleichend. Eine Session pro Paket sieht genau ihr Paket und sonst nichts.

Gepusht wird nachts nie. Der Runner committet lokal und schiebt das Issue nach In review. Morgens entscheide ich.

Modus zwei, der Review

Der zweite Modus baut nichts, er liest. Modelle, die ein Dokument nicht geschrieben haben, prüfen es und hinterlassen ihre Befunde als Kommentar am Board. Der Autor eines Issues hat den Kontext im Kopf, aus dem es entstanden ist, und ergänzt beim Lesen unbewusst, was er nie hingeschrieben hat. Ein fremdes Modell hat nur den Text.

Review und Implementierung laufen in getrennten Nächten. Der Review liest aus dem Backlog, die Implementierung aus Ready, und zwischen beiden Spalten liegt mein „Ready“. Würde ein Lauf ein Ready-Issue erst prüfen und dann bauen, hätte ich meine Freigabe auf einen Text gegeben, der bei der Umsetzung nicht mehr gilt.

Modus drei, die Erzeugung

Der neue Modus erzeugt die nächste Stufe. Aus einer geprüften fachlichen Anforderung entsteht ein Plandokument. Nach meiner Freigabe entstehen aus dem Plan die Arbeitspakete. Und was in dieser Nacht entsteht, wird in derselben Nacht auch gleich geprüft, Runde für Runde, bis jedes Dokument einen Endzustand trägt.

Einen Schritt baue ich dabei gerade noch ein. Wenn die Arbeitspakete fertig sind, läuft ein Abgleich gegen die fachliche Anforderung, und der fragt in beide Richtungen. Decken alle Pakete zusammen jedes Akzeptanzkriterium ab? Und steht in einem Paket etwas, das die Fachlichkeit nie gefordert hat? Die erste Frage findet die Lücke, die zweite den Zuwachs. Beim Lesen eines einzelnen Pakets fällt keins von beidem auf, weil jedes Paket für sich plausibel aussieht. Sichtbar wird es erst, wenn jemand die ganze Menge gegen die Anforderung hält.

Damit ist die technische Planung aus meinem Tag verschwunden. Was ich noch tue, ist die Fachlichkeit. Ich schreibe sie auf, ich lasse sie vom PO groomen und von zwei Modellen aus zwei verschiedenen Modellfamilien lesen, und ich lese sie selbst oft bzw. begebe mich in ein Gespräch mit einem Modell und „groome“. Wenn die Fachlichkeit steht, gebe ich sie mit einem Label frei und der Rest passiert ohne mich.

Was daran nicht automatisch ist

Der Lauf endet nicht immer mit einem fertigen Dokument. Findet ein Prüfer eine Frage, die mehrere gangbare Wege offenlässt, oder verletzt ein Fund eine Regel aus meinen Registern, dann setzt der Runner das Label kit:klaeren und hört auf. Dieses Label nimmt ausschließlich ein Mensch wieder ab. Ein Lauf, der sein eigenes kit:klaeren abräumen dürfte, könnte sich selbst freigeben.

Dasselbe gilt für die Freigabe zwischen den Stufen. Die Routing-Labels sind meine Geste am Board. Deshalb lässt sich das Label für die Erzeugungsnacht auch nicht abschalten, anders als das für den Review.

Übrig bleiben vier Punkte, an denen ich stehe: die Fachlichkeit, die Freigabe des Plans, das Ready für die Umsetzung und am Ende Push und Merge. An diesen vier Stellen wird auch künftig nichts automatisiert, so ist jedenfalls der Stand heute.

Wo ein Fehler jetzt teuer wird

Die Denkarbeit ist nach vorn gewandert, und zwar vollständig. Früher habe ich einen Fehler in der Anforderung im Code gefunden. Heute finde ich ihn in der Anforderung oder gar nicht, weil danach niemand mehr hinschaut, der ihn finden könnte. Ein Fehler in der Fachlichkeit kostet einen Satz. Derselbe Fehler, drei Stufen später, kostet eine Nacht und dreizehn Arbeitspakete.

Deshalb lese ich die Fachlichkeit sehr oft und lasse sie immer gegenlesen. Von einem Menschen und von zwei Modellen aus unterschiedlichen Modellfamilien. Sie ist die letzte Stelle, an der ich einen Fehler billig loswerde.