Sechs Smells eines sterbenden Softwareprojekts
Softwareprojekte kollabieren selten plötzlich.
Meist entwickeln sich über längere Zeit Muster, die auf strukturelle Probleme im System hinweisen.
Diese Muster sind oft früh sichtbar – werden jedoch als normale Projektprobleme interpretiert.
Ähnlich wie Code-Smells weisen auch Projektgerüche auf tieferliegende Ursachen hin.
Ein einzelnes Signal ist selten entscheidend.
Wenn jedoch mehrere gleichzeitig auftreten, deutet vieles auf eine systemische Fehlentwicklung hin.
Kernaussage
Sterbende Softwareprojekte erkennt man selten zuerst am Code.
Sie zeigen sich vor allem im Verhalten von Teams, Organisation und Erwartungen.
1. Sprint Reviews ohne fertige Features
In gesunden Teams demonstrieren Reviews fertige Funktionalität.
Wenn Reviews zunehmend aus Statusberichten bestehen, verschiebt sich der Fokus:
- Arbeit wird beschrieben statt gezeigt
- Fortschritt wird behauptet statt demonstriert
- Ergebnisse werden durch Aktivität ersetzt
Typische Aussagen:
- „Wir haben intensiv an Feature X gearbeitet.“
- „Es gab viele unerwartete Probleme.“
- „Das Feature ist fast fertig.“
Wenn mehrere Sprints ohne fertige Ergebnisse vergehen, ist dies oft ein starkes Signal sinkender Lieferfähigkeit.
2. Bestimmte Bereiche des Systems werden gemieden
In vielen Projekten entstehen Teile der Codebasis, die Entwickler möglichst vermeiden.
Typische Hinweise:
- Änderungen dauern ungewöhnlich lange
- kleine Anpassungen erzeugen große Nebeneffekte
- Entwickler reagieren sichtbar vorsichtig auf Änderungen
Solche Bereiche sind oft Symptome von architektonischer Erosion.
3. Architekturgespräche verschwinden
In gesunden Engineering-Kulturen wird Architektur regelmäßig diskutiert.
Wenn diese Gespräche verschwinden, gibt es meist zwei mögliche Ursachen:
- Die Architektur ist stabil und verstanden.
- Das Team glaubt nicht mehr, dass Verbesserungen realistisch sind.
Der zweite Fall ist deutlich häufiger.
4. Entwickler verlassen das Projekt
Ein besonders verlässlicher Indikator ist Developer Turnover.
Wenn erfahrene Entwickler das Projekt verlassen, kann das viele Gründe haben.
Wenn mehrere gehen, sollte man genauer hinsehen.
Häufige Ursachen sind:
- stagnierende Architektur
- fehlender Einfluss auf Entscheidungen
- dauerhaft niedrige Entwicklungsgeschwindigkeit
Zurück bleiben häufig Teams, die sich an das System angepasst haben.
5. Entscheidungen werden ausschließlich kurzfristig getroffen
Kurzfristige pragmatische Entscheidungen sind in Softwareprojekten normal.
Problematisch wird es, wenn jede Entscheidung nur noch kurzfristig begründet wird.
Typische Aussagen:
- „Das fixen wir später.“
- „Für jetzt reicht es.“
- „Wir müssen einfach durchkommen.“
Diese Entscheidungen akkumulieren über Zeit und verstärken strukturelle Probleme.
6. Erwartungen sinken unbemerkt
Der gefährlichste Smell ist oft der unsichtbarste.
Organisationen beginnen, ihre Erwartungen schrittweise anzupassen.
| Früher | Später |
|---|---|
| Feature im Sprint fertig | Fortschritt im Sprint |
| Architektur verbessern | Risiken vermeiden |
| Qualität sichern | Stabilität erhalten |
Dadurch verschwindet der sichtbare Konflikt zwischen Anspruch und Realität.
Das System wirkt stabil – obwohl seine Leistungsfähigkeit sinkt.
Muster statt Einzelfälle
Keiner dieser Gerüche ist für sich genommen ungewöhnlich.
Fast jedes Projekt erlebt:
- schwierige Module
- verpasste Sprintziele
- technische Kompromisse
Problematisch wird es, wenn mehrere dieser Muster gleichzeitig auftreten und über längere Zeit bestehen bleiben.
Dann deutet vieles darauf hin, dass sich das System in Richtung Stable Failure entwickelt.
Bedeutung für technische Führung
Technische Führung besteht nicht nur aus Architekturentscheidungen.
Sie umfasst auch die Fähigkeit, organisatorische Muster früh zu erkennen.
Denn Softwareprojekte scheitern selten an einem einzelnen Fehler.
Sie sterben meist langsam – und senden ihre Signale lange vorher.