Zum Hauptinhalt springen

Frühe Warnsignale

Softwareprojekte scheitern selten plötzlich.

In den meisten Fällen entwickelt sich der Verfall schrittweise.
Lange bevor ein Projekt sichtbar in Schwierigkeiten gerät, entstehen Muster im Verhalten von Teams und Organisationen.

Diese Signale sind selten isoliert.
Sie treten typischerweise in Kombination auf.

Das frühzeitige Erkennen dieser Muster ist eine der wichtigsten Fähigkeiten technischer Führung.


Kernaussage

Der Zustand eines Softwareprojekts zeigt sich weniger im Code als im Verhalten des Systems aus Menschen, Entscheidungen und Erwartungen.

Wenn mehrere der folgenden Signale gleichzeitig auftreten, ist Vorsicht geboten.


1. Sprint Reviews ohne fertige Features

Ein gesundes Team demonstriert im Review fertige Funktionalität.

Wenn Reviews zunehmend zu Statusberichten werden, verschiebt sich der Fokus:

  • von Lieferung zu Aktivität
  • von Ergebnis zu Rechtfertigung

Typische Formulierungen:

  • „Wir haben an Feature X gearbeitet.“
  • „Ein paar Bugs wurden gefixt.“
  • „Das Feature ist fast fertig.“

Ein Review ohne demonstrierbare Ergebnisse ist oft ein frühes Zeichen sinkender Lieferfähigkeit.


2. Bestimmte Module werden gemieden

In vielen Projekten entstehen Bereiche des Systems, die Entwickler möglichst nicht anfassen wollen.

Typische Symptome:

  • Änderungen dauern ungewöhnlich lange
  • Entwickler wechseln das Thema
  • kleine Anpassungen erzeugen unerwartete Nebeneffekte

Wenn Teams anfangen, Teile der Codebasis zu umgehen oder zu isolieren, ist dies oft ein Hinweis auf architektonische Erosion.


3. Architekturgespräche verschwinden

In gesunden Teams wird Architektur regelmäßig hinterfragt.

Diskussionen drehen sich um:

  • bessere Strukturen
  • klarere Grenzen
  • langfristige Wartbarkeit

Wenn diese Gespräche verschwinden, kann das zwei Ursachen haben:

  1. Die Architektur ist stabil und verstanden.
  2. Das Team hat aufgehört zu glauben, dass Verbesserungen möglich sind.

Der zweite Fall ist deutlich häufiger.


4. Technische Entscheidungen werden rein pragmatisch

Pragmatismus ist ein wichtiger Bestandteil von Softwareentwicklung.

Problematisch wird er, wenn jede Entscheidung ausschließlich kurzfristig motiviert ist.

Typische Aussagen:

  • „Das fixen wir später.“
  • „Für jetzt reicht es.“
  • „Wir müssen einfach durchkommen.“

Wenn solche Entscheidungen zum Standard werden, entsteht eine kumulative Verschlechterung der Systemstruktur.


5. Entwicklerfluktuation steigt

Technische Kennzahlen sind oft schwer zu interpretieren.

Ein Indikator ist jedoch erstaunlich zuverlässig:

Developer Turnover.

Wenn erfahrene Entwickler ein Projekt verlassen, kann das viele Gründe haben.
Wenn mehrere gehen, sollte man genauer hinsehen.

Häufige Ursachen:

  • fehlender Einfluss auf technische Entscheidungen
  • stagnierende Architektur
  • sinkende Entwicklungsgeschwindigkeit

Was bleibt, ist oft ein Team, das sich an das System angepasst hat.


6. Erwartungen werden reduziert

Ein besonders gefährliches Signal ist die schrittweise Anpassung der Erwartungen.

Typische Veränderungen:

FrüherSpäter
Feature im Sprint fertigFortschritt im Sprint ausreichend
Architektur verbessernProbleme umgehen
Qualität sichernProduktion stabil halten

Organisationen stabilisieren sich häufig, indem sie Erwartungen an die Realität anpassen.

Dadurch verschwindet der sichtbare Konflikt zwischen Anspruch und Ergebnis.


Muster statt Einzelindikatoren

Keines dieser Signale ist allein entscheidend.

Fast jedes Projekt erlebt zeitweise:

  • verpasste Sprintziele
  • schwierige Module
  • technische Kompromisse

Problematisch wird es, wenn mehrere Signale gleichzeitig auftreten und über längere Zeit bestehen bleiben.

Dann deutet vieles darauf hin, dass das System in Richtung Stable Failure driftet.


Beobachtung statt Schuldzuweisung

Frühe Warnsignale sind keine individuellen Fehler.

Sie entstehen aus dem Zusammenspiel von:

  • Architektur
  • Organisation
  • Erwartungsmanagement
  • Produktdruck

Die Aufgabe technischer Führung besteht daher nicht darin, Schuldige zu suchen, sondern Systemdynamiken zu erkennen und sichtbar zu machen.

Denn Softwareprojekte scheitern selten plötzlich.

Sie senden ihre Warnsignale meist lange vorher.

Weiterführende Artikel