Was acht Monate Alleinbau lehren, das keine Theorie sagen kann

Die ersten drei Artikel dieser Serie waren Theorie: warum Scrum an sein Ende kommt, warum SAFe das falsche Problem löst, welche drei Achsen jede Methode wirklich unterscheiden. Dieser Artikel ist kein Framework mehr. Er ist ein Erfahrungsbericht.

Der Unterschied zwischen einer Idee und einem Werkzeug, das an sich selbst getestet wird

Eine Methodik, die nur auf dem Papier existiert, kann beliebig überzeugend klingen. Der eigentliche Test beginnt erst, wenn man sie an einem echten Projekt anwendet — und zwar nicht an einem Beispielprojekt, das eigens zur Illustration gebaut wurde, sondern an einem Projekt, dessen Erfolg tatsächlich davon abhängt, dass die Methodik hält, was sie verspricht.

Genau das ist seit acht Monaten mein Alltag: ein Softwareprojekt, das nach seinen eigenen Regeln entsteht, während diese Regeln selbst noch geschärft werden. Kein Team, das mir bei der Einordnung hilft. Keine Kollegen, mit denen ich die Ansätze im Detail durchsprechen könnte, weil das Thema für die meisten noch zu neu ist. Ein einzelner Mensch, ein KI-Partner, und ein Projekt, das ehrlich genug sein muss, um eigene Fehler nicht zu verstecken.

Drei Fehler, die die Theorie nicht vorhergesagt hätte

Nach 48 durchgearbeiteten Anforderungen in einer langlebigen Arbeitssitzung traten kurz hintereinander drei echte Fehler auf: eine erfundene Quellenangabe, eine falsch zugeordnete Begründung, ein Logikfehler, der bei genauem Hinsehen keinen Sinn ergab. Keiner dieser Fehler war dramatisch für sich genommen. Zusammengenommen zeigten sie ein Muster: Nach einer gewissen Kontextlänge lässt die Zuverlässigkeit spürbar nach, selbst wenn nichts davon nach außen sichtbar wird, solange niemand gezielt danach sucht.

Der eigentlich interessante Teil ist nicht, dass diese Fehler passiert sind. Fehler passieren, mit oder ohne KI, mit oder ohne Methodik. Der interessante Teil ist, dass eine unabhängig geprüfte, in frischem Kontext arbeitende zweite Instanz alle drei gefangen hat — nicht, weil sie disziplinierter gewesen wäre, sondern weil sie strukturell kein Vorwissen hatte, an dem sich ein Fehler hätte festsetzen können. Das ist der Unterschied zwischen "wir prüfen sorgfältig" und "eine Prüfung, die aufgrund ihrer Konstruktion gar nicht anders kann, als unvoreingenommen zu sein".

Warum ein fester Rhythmus wichtiger war als erwartet

Eine der praktischen Lehren aus diesen acht Monaten: Es reicht nicht, eine gute Prüfinstanz zu haben. Es braucht auch einen festen Punkt, an dem eine lange, produktive Arbeitssitzung bewusst beendet und neu gestartet wird — nicht erst, wenn ein Fehler bereits sichtbar geworden ist, sondern vorbeugend, nach einer festen Anzahl bearbeiteter Punkte. Dieser Rhythmus hat sich in der Praxis sowohl reaktiv bewährt, als Reaktion auf entdeckte Fehler, als auch präventiv, ganz ohne dass vorher etwas schiefgegangen wäre. Beides zusammen war nötig. Eine gute Prüfinstanz allein hätte die Fehler gefunden, aber erst, nachdem sie schon mehrfach passiert waren.

Was das für die Methodik bedeutet — und was es nicht bedeutet

Diese Fehler sind kein Gegenargument gegen den Ansatz. Sie sind der Grund, warum der Ansatz überhaupt glaubwürdig ist. Eine Methodik, die behauptet, nie an eigene Grenzen zu stoßen, wäre nicht seriös. Eine Methodik, die eigene Grenzen offen dokumentiert und zeigt, dass ihr eigener Prüfmechanismus genau diese Grenzen zuverlässig auffängt, ist etwas anderes — sie beweist sich an der Stelle, an der es wirklich zählt.

Was diese acht Monate nicht beweisen: dass der Ansatz genauso gut funktioniert, wenn mehrere echte Menschen mit unterschiedlichen, tatsächlich widerstreitenden Interessen beteiligt sind, statt eines einzelnen Entscheiders. Das ist eine offene Frage, keine bereits beantwortete.

Im nächsten Artikel geht es um das, was aus diesen acht Monaten tatsächlich entsteht: ein Werkzeug, das die eigene Methodik nicht nur beschreibt, sondern gegen sich selbst prüfbar macht.