Softwarefluss ist kein Prozesstheater

9 Min. Lesezeit

Die Arbeit fließt – oder sie verrottet

Flow ist zuerst ein Führungsthema und erst danach ein Gefühl des Entwicklers. Ein Entwickler mit Kopfhörern, der vier Stunden konzentriert arbeitet, mag sich in einem angenehmen mentalen Zustand befinden. Wunderbar. Kaufen Sie ihm bessere Kopfhörer. Aber das ist nicht der Flow, den die Führung verstehen muss.

Entscheidend ist der Flow des gesamten Systems. Ein Bedarf eines Kunden wird sichtbar. Eine Entscheidung wird getroffen. Entwickler formen daraus eine kleine Änderung. Die Änderung wird getestet, integriert, geprüft, veröffentlicht, beobachtet und verbessert. Die Organisation lernt etwas, das tatsächlich stimmt. Dann fließt die nächste Änderung. Oder sie fließt nicht – und dort beginnt die teure Wirklichkeit.

Die meiste Softwarearbeit scheitert nicht daran, dass Entwickler das Tippen verlernt haben. Sie scheitert daran, dass Arbeit zwischen Zuständen feststeckt: Sie wartet auf Entscheidungen, Klärung, Review, ein anderes Team, Testumgebungen, Deployment-Fenster oder jemanden, der mutig genug ist, das alte Modul anzufassen. Die Arbeit kann trotzdem aktiv aussehen. Sie fließt nicht. Sie altert.

Flow ist nicht Bewegung

Die nützliche Definition für die Führung ist einfach genug, um gefährlich zu sein: Flow ist die Bewegung von Wert durch ein System. Nicht Aufgaben. Nicht Aufwand. Nicht Stunden. Wert.

Bei Software entsteht Wert, wenn funktionierende Software tatsächlich genutzt wird. Alles davor ist Bewegung in Richtung Wert, nicht der Wert selbst.

Wenn die Lieferfähigkeit nachlässt, verfolgen Sie den Weg. Wo kommt wertvolle Arbeit zum Stillstand – und warum? Ein langsames Review braucht ein schnelleres Review. Ein fragiles Deployment braucht ein sichereres Deployment. Unklare Produktverantwortung braucht eine Entscheidung. Eine Codebasis, die niemand sicher ändern kann, braucht technische Arbeit. Das Hindernis bestimmt die Reaktion.

Die Entwicklungsschleife wurde schon einmal gelöst

Extreme Programming, meist zu XP abgekürzt, war keine Imagekampagne für Entwickler, die Disziplin mochten. Es war eine Sammlung von Arbeitspraktiken für eine Welt, in der Software sich ständig ändert und Menschen sich mehrmals täglich irren: Pair Programming, testgetriebene Entwicklung, Refactoring, Continuous Integration, kleine Releases, einfaches Design, gemeinsame Verantwortung, ein Kunde vor Ort und ein nachhaltiges Arbeitstempo.

Diese Praktiken verstärken sich gegenseitig, weil sie den Flow schützen: schnelleres Feedback, kleinere Pakete, sicherere Integration, leichtere Änderungen und weniger Abhängigkeit von Spezialisten.

Diese lokale Verbesserung war erfolgreich. Genau deshalb wurde sie politisch unbequem. Sobald die Entwicklungsschleife besser funktioniert, können sich die nächsten Engpässe nicht länger hinter der Aktivität der Entwickler verstecken. Wenn das Team eine kleine Idee schnell in getesteten Code verwandeln kann, die Arbeit aber trotzdem wartet, liegt die Verzögerung woanders: bei Produktentscheidungen, Freigabeschranken, Angst vor Deployments, Abhängigkeiten zwischen Teams, einer Architektur ohne Verantwortliche, der Koordination mit Anbietern oder als Vorsicht getarnter Unentschlossenheit der Geschäftsleitung.

Die Geschichte von Chryslers Lohnabrechnung macht es unmöglich, dieses Muster als Fiktion abzutun. Wie in Was ist mit Agile passiert? beschrieben, hatte C3 nach drei Jahren traditioneller Entwicklung nicht eine einzige Gehaltsabrechnung produziert. Nachdem die Praktiken eingeführt worden waren, aus denen XP entstand, ging das System innerhalb von ungefähr einem Jahr live. Nach der Fusion von Daimler und Chrysler wurde das Projekt später eingestellt und XP faktisch verworfen.

Die Einzelheiten unterscheiden sich von Unternehmen zu Unternehmen. Die Wunde bleibt dieselbe. Technische Disziplin beginnt zu wirken, macht das echte System sichtbar und verändert, wer sagen kann, was wahr ist. Die Führung kann das Hindernis beseitigen. Oder sie kann ihre Kultur verteidigen, indem sie die Praktik – oder die Person – entfernt, die es offengelegt hat.

Technische Disziplin brachte C3 voran. Das Management brachte das Projekt trotzdem zu Fall. Softwarefluss braucht sowohl eine veränderbare Codebasis als auch eine Organisation, die bereit ist, nach den Erkenntnissen aus der Arbeit zu handeln.

Flow braucht eine echte Eintrittsschwelle

Echter Flow braucht eine Schwelle. Bevor eine Aufgabe in die Umsetzung geht, muss jemand, der nah genug am Code und an den Folgen ist, guten Gewissens sagen können: „Ja, dieses Stück ist klar genug und klein genug, um es fertigzustellen.“ Nicht anzufangen. Fertigzustellen. Dieser Unterschied zählt. Unklare Arbeit zu beginnen, erzeugt nur mehr parallele Arbeit und verschiebt die Verzögerung nach hinten.

Deshalb ist auch Ablehnung wichtig. Entwickler müssen Arbeit zurückgeben können, wenn der Zuschnitt falsch ist, Unbekanntes versteckt wird oder eine Entscheidung noch immer unfertig ist. Unklare Arbeit zu beginnen, erzeugt keinen Flow. Es verschiebt die Unsicherheit nach hinten, wo daraus Verzögerung, Nacharbeit und Enttäuschung werden.

Softwarefluss ist keine Fließbandarbeit

Warteschlangen sind wichtig. Übergaben sind wichtig. Die Paketgröße ist wichtig. Verzögerungen sind teuer. Aber Softwarearbeit ist nicht bloß die Verarbeitung bekannter Eingaben. Sie ist Untersuchung, Gestaltung, Verhandlung und das Entdecken von Grenzen – vermischt mit der Umsetzung.

Industrielle Sprache ist verlockend, weil sie diese Unsicherheit in einer Budgetsitzung kontrollierbar erscheinen lässt. Durchsatz. Kapazität. Takt. Zusagen. Keines dieser Wörter verrät, ob Tests Vertrauen schaffen, die Architektur Änderungen unterstützt, Deployments Routine sind oder die Produktentscheidung sinnvoll ist.

Softwaremanagement zieht eine Sorte Berater an, die nie eine Zeile Produktionscode geschrieben haben. Manche haben vor Jahrzehnten an der Universität ein wenig programmiert und erklären die Arbeit seitdem anderen. Sie beherrschen das Vokabular der Produktion, ohne je deren Folgen getragen zu haben. Kein gescheitertes Deployment um 02:00 Uhr. Kein Rollback, während Kunden warten. Kein Refactoring, das jahrelang verborgene Kopplungen freilegt. Keine Narben aus dem Spiel. Ihre Gewissheit bleibt makellos, weil das Risiko immer jemand anderes getragen hat.

Softwarefluss verbessert sich, wenn die echten Ursachen von Verzögerung und Unsicherheit verringert werden: kleinere, klar abgegrenzte Änderungen, klarere Produktentscheidungen, stärkere Tests, sicherere Deployments, besseres Design, weniger Wissenskonzentration und schnelleres Feedback aus der Nutzung.

Flow muss in die Codebasis gelangen

Sichtbarkeit kann zeigen, wo Arbeit wartet. Sie kann keine Testsuite reparieren, Abhängigkeiten entflechten, Deployments langweilig machen oder eine Produktentscheidung klären. Flow verbessert sich erst, wenn das Hindernis verändert wird.

Der Gegensatz spielt sich bereits in The Last Batch ab. In Der Lauf sagt die Wahrheit hat Whitaker Payroll bereits einen Berater engagiert, der Dashboards, Planbarkeit und Schlaf verspricht. Er kommt mit PowerPoint und Farbverläufen, hält zwölf Tage durch und hinterlässt einen Ordner. Ethan Carter kommt ohne Folien und baut ein Testgerüst um den COBOL-Batch. Als es einen echten Fehler in der Lohnabrechnung aufdeckt, widerlegt die Führung die Zahl nicht. In Draußen vor der Tür wechselt sie das Thema zu Rollenklarheit, Eignung, Umfang und Führung, streicht Ethans Budgetposten und lässt einen gesperrten Dienstausweis die Entlassung vollziehen. Die Prozessgeschichte bleibt unversehrt. Die Software bleibt falsch.

Ist der Engpass technisch, muss die Lösung in die Codebasis gelangen.

Ist der Engpass die Konzentration von Wissen, muss die Lösung Pairing, Review und Verantwortung verändern.

Ist der Engpass langsames Feedback, muss die Lösung Tests, Deployment, Beobachtbarkeit und Produktzugang verändern.

Flow ist ein Führungsthema, aber Softwarefluss lässt sich nicht aus einem Konferenzraum steuern. Jemand muss am Code, an der Pipeline, an den Tests und an den unbequemen Absprachen zwischen Menschen arbeiten.

Dafür braucht es genügend Urteilsvermögen in der Softwareentwicklung, um das Führungsanliegen mit der Entwicklungswirklichkeit zu verbinden und den Engpass dort zu beseitigen, wo er tatsächlich liegt.

Geschwindigkeit ohne Flow ist nur eine schnellere Methode, Arbeitsvorräte aufzubauen.

KI macht die Ausrede schwächer

KI hat die Disziplin der Softwareentwicklung nicht überflüssig gemacht. Sie hat es schwerer gemacht, das Argument für Flow zu ignorieren. Ein Agent kann heute in Minuten eine plausible Änderung erzeugen. Die Warteschlangen liegen bloß: Review, Antworten auf Produktfragen, Integration, Deployment und Urteilsvermögen beim Design.

KI wird das Refactoring nicht zuverlässig von sich aus anbieten. Sie wird häufig das vorhandene Muster fortsetzen. Wenn das Entwicklungssystem schwache Tests, langsame Reviews, unklare Verantwortung und fragile Deployments hat, schüttet KI noch mehr Arbeit in diese Schwäche.

Das macht KI nicht schlecht. Es macht den Flow sichtbar. Je besser das Liefersystem, desto nützlicher wird KI. Je schlechter das System, desto schneller füllt KI seine Warteschlangen. Fragen Sie, warum die Organisation die Änderungen nicht aufnehmen kann, die ihre Entwickler und Werkzeuge bereits erzeugen können.

Was Führungskräfte sehen sollten

Nützliche Fragen klingen so:

• Wie lange braucht eine kleine Änderung von der Entscheidung bis zur Produktion?
• Wo wartet sie?
• Welches Modul oder welcher Dienst bremst Änderungen immer wieder aus?
• Wie schnell wird aus einem Fehler ein ausführbarer Test?
• Wie viele Entscheidungen verzögern sich, weil niemand mit Befugnis nah genug an der Arbeit ist?
• Welche Arbeit altert gerade?

Diese Fragen legen offen, ob die Praktiken echt sind. Ein Team, das Continuous Integration behauptet, während seine Branches zehn Tage bestehen bleiben, hat keine Continuous Integration. Ein Team, das gemeinsame Verantwortung behauptet, während jede wichtige Änderung auf eine Person wartet, hat keine gemeinsame Verantwortung.

Flow macht die Wahrheit sichtbar. Diese Wahrheit kann lauten, dass die Entwickler lokal bereits ausreichend optimiert wurden. Die verbleibende Verzögerung kann aus der Unfähigkeit der Organisation entstehen, Entscheidungen zu treffen, Reviews durchzuführen, Deployments zu beherrschen, Arbeit zu finanzieren, Komplexität zu verringern oder die Folgen ihrer eigenen Anforderungen zu verantworten.

Führungskräfte sollten sich für die Mechanik der Softwareentwicklung interessieren, auch wenn sie nie die alten Bezeichnungen verwenden. Die Bezeichnung ist optional. Die Mechanik ist es nicht.

Flow ist der Punkt

Flow fragt, ob wertvolle Änderungen schnell genug in die Nutzung gelangen, damit die Organisation lernt, solange die Informationen noch zählen. Er fragt, ob Feedback früh genug kommt, um die Richtung zu ändern, ob die Codebasis sicher veränderbar bleibt, ob Wissen durch das Team fließt und ob die Führung noch immer den Teil optimiert, der längst nicht mehr der Engpass ist.

Das ist Flow: wertvolle Änderungen, die sich durch ein lebendiges System bewegen, ohne von Warteschlangen, Angst, Unwissen oder Verzögerung erwürgt zu werden. Wenn Code schneller entsteht, als die Organisation ihn aufnehmen kann, wird der Rest der Organisation sichtbar. Die Frage ist, ob die Führung den Engpass beseitigt oder den Menschen, der ihn offengelegt hat.