Hauptgedanke

Code zu schreiben kostete Zeit, und diese Kosten hatten eine Nebenwirkung, die niemand beschlossen hatte: Bevor es weiterging, musste man oft darüber reden, abwägen, gegenlesen lassen, verstehen, was man tat. Das Verständnis war nicht durch eine Disziplin gesichert, es wurde vom Preis jeder Handlung erzwungen.

Wenn ein paar Stunden genügen, wo früher mehrere Tage nötig waren, fällt diese faktische Schutzvorrichtung weg — und sie hinterlässt nichts, weil sie nie eingerichtet worden war. Man kann dann schneller vorankommen, als man selbst versteht: Bildschirme antworten, eine Datenbank existiert, eine API läuft, und kein Moment zwingt dazu zu wissen, warum die Dinge so gebaut sind.

Die fehlende Disziplin ist also keine verlorene Disziplin: Es ist eine, die nie existieren musste und die man zum ersten Mal aufschreiben muss.

Warum das wichtig ist

Das erklärt, warum auch die erfahrensten Teams überrascht werden. Sie haben ihre Praktiken nicht schleifen lassen; sie haben einen unbeabsichtigten Mechanismus verloren, auf den sich ihre Praktiken stützten, ohne dass sie es wussten.

Es weist auch die Richtung für die Abhilfe: Es geht nicht darum, zu den Praktiken von früher zurückzukehren, sondern ausdrücklich zu machen — verpflichtendes Review, schriftlich festgehaltene Architekturentscheidung, Verständnisbudget pro Feature —, was die Langsamkeit kostenlos hervorbrachte.

Nuancen und Grenzen

Über das eigene Verständnis hinauszugehen ist nicht immer ein Fehler: Genau das sucht man beim Erkunden, wenn man sehen will, wie eine Lösung aussähe, bevor man weiß, ob sie etwas taugt. Gefährlich wird es, wenn die Erkundung zur Produktion wird, ohne dass jemand den Übergang ausdrücklich beschlossen hat.

Und die Langsamkeit erzwang das Gespräch, ohne je seine Qualität zu garantieren: Viele langsame Systeme wurden trotzdem schlecht verstanden.

Offene Fragen

• An welchem Signal erkennt ein Team, dass ein explorativer Prototyp gerade ohne ausdrückliche Entscheidung in die Produktion befördert wurde?