EP014: Warum Scrum Teams oft nicht liefern

Worum es geht

Situation: In vielen Organisationen arbeiten Teams nach Scrum, halten alle Events ab und liefern dennoch konsistent nicht das, was sich Führungskräfte und Stakeholder erhoffen. Die Retrospektiven drehen sich im Kreis, und der Frust wächst auf allen Seiten.

Komplikation: Das Problem ist oft nicht die mangelnde Anstrengung oder fehlendes Wissen des Teams. Was ich konsistent beobachte ist, dass Teams in einem System arbeiten, das echte Lieferung strukturell verhindert. Sie optimieren lokale Metriken (wie die Velocity) und feiern das "Sprint-Ziel erreicht", während die eigentliche Wertlieferung an den Kuten in einer Grauzone zwischen den Teams versickert.

Frage: Woran liegt es wirklich, wenn Scrum Teams nicht liefern? Und welche Hebel müssen wir umlegen, um von Schein- zu echter Lieferfähigkeit zu kommen?

Für wen?

Episoden-Insights

1. Der Mythos vom "Done" und die Realität der Lieferung

Viele Teams verwechseln "Sprint-Ziel erreicht" mit "Wert geliefert". Die Arbeit ist vielleicht "done" nach Definition des Teams, aber sie liegt wochenlang bei einer Infrastruktur-Abteilung, im Security-Review oder wartet auf ein Deployment-Fenster. Diese Zeit zwischen "done" und "beim Kunden" ist unsichtbar und wird nicht gemessen – aber sie tötet die Lieferfähigkeit. Wir optimieren den falschen Teil des Prozesses.

"Was ich konsistent beobachte ist, dass Teams ihr Sprint-Ziel feiern, während die eigentliche Lieferung noch Lichtjahre entfernt ist. Das ist, als würde man einen Marathon feiern, nachdem man die erste Meile gelaufen ist."

2. Abhängigkeiten sind das strukturelle Gift für Flow

Die größte Bremse für Teams sind nicht fehlende Fähigkeiten, sondern Abhängigkeiten. Warten auf ein anderes Team, auf eine Genehmigung, auf einen externen Dienstleister. Diese Wartezeiten werden internalisiert und als "normal" akzeptiert. Das Team fühlt sich beschäftigt (weil es an anderen Tasks arbeitet), aber der Wert fließt nicht. Echte Lieferfähigkeit entsteht, wenn Teams diese Abhängigkeiten sichtbar machen und das System so umbauen, dass sie verschwinden oder minimiert werden.

3. Metriken lenken das Verhalten – leider oft in die falsche Richtung

Wenn wir nur messen, wie viele Story Points ein Team pro Sprint schafft (Velocity), dann wird das Team alles tun, um diese Zahl zu optimieren. Das führt zu größeren Stories, Aufblähen von Schätzungen und Ignorieren von allem, was nicht in diese Metrik passt – wie eben das Auflösen von Abhängigkeiten. Wir brauchen Metriken, die auf den Gesamterfolg abzielen, wie die End-to-End Cycle Time (von der Idee bis zur Produktion) oder die Deployment Frequency.

Dein nächster Schritt

Kommt dir das bekannt vor? Die Diskussion über echte Lieferfähigkeit ist komplex und sehr kontextabhängig. Lasst uns mal gemeinsam abgleichen, wo bei euch die größten Hebel liegen.