Institutionalized Failure
Die meisten Softwareprojekte scheitern nicht plötzlich.
Stattdessen entwickeln sie über längere Zeit Strukturen und Verhaltensweisen, die einen Zustand stabilisieren, in dem Fortschritt ausbleibt, das System jedoch weiterhin betrieben wird.
Dieser Zustand kann als Institutionalized Failure beschrieben werden.
Das Projekt funktioniert weiterhin organisatorisch – Sprints finden statt, Releases werden geplant, Teams arbeiten – doch echte Verbesserung des Systems findet kaum noch statt.
Kernaussage
Institutionalized Failure entsteht, wenn eine Organisation ihre Erwartungen und Arbeitsweisen so anpasst, dass ein dauerhaft dysfunktionales System stabil betrieben werden kann.
Das Problem wird nicht mehr gelöst, sondern organisational absorbiert.
Typische Merkmale
Mehrere charakteristische Muster treten häufig gemeinsam auf.
Fortschritt wird durch Aktivität ersetzt
In gesunden Projekten wird Fortschritt an fertigen Ergebnissen gemessen.
In institutionalisierten Fehlersystemen verschiebt sich der Fokus:
- Arbeit wird beschrieben, nicht Ergebnisse
- Fortschritt wird über Aufwand dargestellt
- Statusberichte ersetzen Demonstrationen
Typische Aussagen:
- „Wir haben intensiv daran gearbeitet.“
- „Das Feature ist fast fertig.“
- „Es gab viele unerwartete Probleme.“
Erwartungsniveau sinkt
Ein entscheidender Stabilisationsmechanismus ist die Anpassung der Erwartungen.
Anforderungen an Geschwindigkeit, Qualität und Architektur werden schrittweise reduziert.
| Früheres Ziel | Neues Ziel |
|---|---|
| Feature im Sprint abschließen | Fortschritt zeigen |
| Architektur verbessern | Risiken vermeiden |
| Qualität sichern | Stabilität bewahren |
Dadurch verschwindet der sichtbare Konflikt zwischen Anspruch und Realität.
Teams optimieren auf Überleben
In diesem Zustand richten Entwickler ihre Arbeit nicht mehr primär auf Verbesserung des Systems aus.
Stattdessen entstehen Überlebensstrategien:
- riskante Änderungen vermeiden
- schwierige Bereiche des Systems umgehen
- möglichst wenig Angriffsfläche bieten
Die Energie des Teams fließt in Stabilisierung, nicht in Weiterentwicklung.
Architektur wird nicht mehr hinterfragt
In funktionierenden Engineering-Kulturen wird Architektur regelmäßig diskutiert und verbessert.
Im Zustand institutionalisierten Scheiterns verschwinden solche Gespräche.
Typische Gründe:
- Änderungen erscheinen zu riskant
- frühere Verbesserungsversuche sind gescheitert
- Einfluss auf Entscheidungen wird als gering wahrgenommen
Die Architektur wird dadurch implizit eingefroren.
Fluktuation stabilisiert das System
Erfahrene Entwickler verlassen häufig als erste ein stagnierendes System.
Zurück bleiben oft Personen, die:
- sich an das System angepasst haben
- geringere Erwartungen an Veränderung haben
- Stabilität höher bewerten als Verbesserung
Die Organisation erreicht damit einen Zustand stabiler Anpassung.
Warum dieser Zustand stabil bleibt
Von außen wirkt Institutionalized Failure oft irrational.
Mehrere Faktoren tragen jedoch zur Stabilität bei:
- das Produkt generiert weiterhin Einnahmen
- ein grundlegender Neustart erscheint zu teuer
- organisatorische Konflikte werden vermieden
- Verantwortlichkeiten sind diffus
Das System funktioniert daher weiterhin – allerdings auf einem deutlich niedrigeren Leistungsniveau.
Beziehung zu Stable Failure
Institutionalized Failure ist kein plötzlicher Zustand.
Er entsteht typischerweise nach einer Phase zunehmender Dysfunktion.
Eine vereinfachte Entwicklung:
- Healthy System
- Strained System
- Dysfunctional System
- Institutionalized Failure
Der entscheidende Übergang besteht darin, dass das System aufhört, sich selbst zu korrigieren.
Konsequenzen für technische Führung
In dieser Phase sind rein technische Maßnahmen selten ausreichend.
Refactoring, neue Tools oder Prozessanpassungen greifen nur begrenzt, solange die zugrunde liegenden organisatorischen Muster unverändert bleiben.
Die eigentliche Herausforderung besteht darin, die Systemdynamik sichtbar zu machen, bevor sie vollständig normalisiert wird.
Denn je länger Institutionalized Failure besteht, desto stärker stabilisiert sich das System um diesen Zustand herum.