Stable Failure
Viele Softwareprojekte scheitern nicht plötzlich.
Stattdessen entwickeln sie über längere Zeit Strukturen, in denen Fortschritt immer schwieriger wird, während das System organisatorisch weiterhin funktioniert.
Sprints finden statt.
Code wird geschrieben.
Meetings werden durchgeführt.
Doch echte Verbesserung des Systems bleibt aus.
Dieser Zustand kann als Stable Failure beschrieben werden.
Das Projekt funktioniert weiterhin – aber auf einem zunehmend niedrigen Niveau an Effektivität.
Kernaussage
Stable Failure beschreibt einen Zustand, in dem ein Softwareprojekt strukturell dysfunktional geworden ist, sich organisatorisch jedoch stabilisiert hat.
Das System läuft weiter, obwohl seine Fähigkeit zur Verbesserung weitgehend verloren gegangen ist.
Der schleichende Übergang
Stable Failure entsteht selten abrupt.
Die meisten Projekte durchlaufen eine schrittweise Entwicklung:
| Phase | Beschreibung |
|---|---|
| Healthy System | Architektur entwickelt sich weiter, Teams verbessern das System aktiv |
| Strained System | Änderungen werden langsamer, Komplexität nimmt zu |
| Dysfunctional System | Features werden schwer fertiggestellt, Bugs dominieren |
| Stable Failure | Das System funktioniert organisatorisch weiter, Verbesserung bleibt aus |
Der entscheidende Übergang besteht darin, dass das System aufhört, sich selbst zu korrigieren.
Warum dieser Zustand stabil bleibt
Von außen wirkt Stable Failure oft paradox.
Warum verändert die Organisation ein offensichtlich problematisches System nicht?
Mehrere Faktoren tragen zur Stabilität bei:
- das Produkt generiert weiterhin Umsatz
- ein grundlegender Neustart erscheint zu teuer
- organisatorische Konflikte werden vermieden
- Verantwortlichkeiten bleiben unklar
Die Organisation passt sich an die Grenzen des Systems an.
Stabilisierung durch Erwartungsanpassung
Ein wichtiger Mechanismus ist die schrittweise Anpassung der Erwartungen.
Wenn Features länger dauern, werden Zeitpläne angepasst.
Wenn Architekturprobleme bestehen bleiben, werden Workarounds akzeptiert.
Dadurch reduziert sich der sichtbare Konflikt zwischen Anspruch und Realität.
Das System stabilisiert sich – allerdings auf einem niedrigeren Leistungsniveau.
Verhalten von Teams
In dieser Phase verändern sich häufig auch die Arbeitsmuster von Teams.
Typische Anpassungen sind:
- riskante Änderungen werden vermieden
- schwierige Bereiche des Systems werden umgangen
- Verbesserungen erscheinen zu teuer oder zu unsicher
Die Energie des Teams fließt zunehmend in Stabilisierung statt in Weiterentwicklung.
Die Rolle organisatorischer Dynamik
Stable Failure ist selten ausschließlich ein technisches Problem.
Es entsteht meist aus dem Zusammenspiel von:
- Architekturentscheidungen
- Organisationsstruktur
- Erwartungsmanagement
- Produktdruck
Die technischen Symptome sind sichtbar, die Ursachen liegen jedoch oft tiefer im System der Organisation.
Bedeutung für technische Führung
Das frühzeitige Erkennen dieses Zustands ist eine zentrale Aufgabe technischer Führung.
Denn Stable Failure entsteht selten über Nacht.
Die meisten Systeme senden lange vorher Signale:
- sinkende Lieferfähigkeit
- steigende Komplexität
- wachsende Entwicklerfluktuation
- verschwundene Architekturgespräche
Diese Signale zu erkennen, bevor sie zur Normalität werden, entscheidet häufig darüber, ob ein System sich noch korrigieren kann.