Warum agile Teams beschäftigt wirken, aber wenig liefern

Das Board ist voll. Anforderungen sind gezogen. Der Sprint läuft. Und trotzdem entsteht das nagende Gefühl, dass zu wenig ankommt. Reviews fallen kleiner aus als geplant. Stakeholder sind unzufrieden. Das Team ist erschöpft — ohne klares Gefühl, wofür eigentlich.

Dieses Muster ist kein Einzelfall. Es ist eines der verbreitetsten und gleichzeitig am häufigsten falsch diagnostizierten Probleme in agilen Organisationen. Und es hat einen Namen: beschäftigt sein ist nicht dasselbe wie liefern.

Was man von außen sieht — die Symptome

Die Signale sind erkennbar, wenn man weiß, worauf man achten muss:

• Hoher Work-in-Progress, niedrige Fertigstellungsrate. Viele Karten bewegen sich auf dem Board — aber wenige erreichen „Done". Das Burndown-Chart sieht flach aus oder verläuft unregelmäßig, weil Items ständig neu hinzukommen.
• Anforderungen verändern sich im Sprint. Eine Story startet, erhält halbwegs Richtung, dann kommt eine neue Anforderung — als dringend markiert — und verschiebt die Priorität. Der Sprint endet mit Halbfertigem. Die nächste Planung beginnt mit Altlasten.
• Das Team wird ständig unterbrochen. Stakeholder fragen direkt nach. Der Product Owner klärt Anforderungen während des Sprints, was vor dem Sprint hätte geschehen sollen. Rückfragen und kurze Abstimmungen kosten stündlich Zeit — jede einzeln klein, zusammen erheblich.
• Meetings dominieren die Arbeitszeit. Wenn mehr als 25–30 % der tatsächlich verfügbaren Zeit in Meetings geht, bleibt wenig für konzentriertes Arbeiten. In manchen Teams liegt dieser Anteil höher — und echte Arbeit wandert in Randzeiten oder bleibt liegen.

Was wirklich dahintersteckt — die Ursachen

Diese Symptome sind keine zufälligen Fehler. Sie sind Indikatoren für ein Systemproblem. Die häufigsten Ursachen:

Zu viel gleichzeitig — fehlende WIP-Beschränkung.
Wenn alles gleichzeitig wichtig ist, ist nichts wirklich wichtig. In Teams ohne bewusste WIP-Limits wächst der Bestand an parallelen Aufgaben, weil jede neue Anforderung sofort in den Sprint eingespeist wird. Das Ergebnis: Viel in Arbeit, wenig fertig. Dieser Zusammenhang ist gut belegt: Je mehr Items gleichzeitig bearbeitet werden, desto länger dauert jedes einzelne bis zur Fertigstellung. Littles Gesetz macht das mathematisch sichtbar. Das agile System löst das nur, wenn Teams bewusst Grenzen ziehen — und wenn diese Grenzen akzeptiert werden.

Anforderungen, die zum Startpunkt noch nicht entscheidungsreif sind.
Viele Teams beginnen Sprints mit Stories, die groß genug aussehen, um gezogen zu werden — aber deren Kern noch unklar ist. Fragen tauchen erst auf, wenn jemand wirklich mit der Umsetzung beginnt. Das führt zu Klärungs-Schleifen, Blockaden und halben Lösungen. Das ist kein Versagen des Teams. Es ist das Ergebnis eines fehlenden Refinement-Prozesses und unklarer Akzeptanzkriterien — beides Aufgaben, die vor dem Sprint erledigt sein sollten.

Keine echte Priorisierung — alles ist dringend.
Wenn Product Owner oder Führungskräfte alle Anforderungen mit der gleichen Dringlichkeit behandeln, fehlt dem Team die Entscheidungsgrundlage. Was dann geschieht: Das Team priorisiert selbst — nach eigenem Ermessen, nach der Lautstärke der Anforderenden oder nach technischer Neigung. Das führt selten zum geschäftlich wichtigsten Ergebnis. Echte Priorisierung bedeutet, Nein zu sagen. Das setzt Entscheidungsmandat voraus — etwas, das Product Ownern häufig fehlt oder entzogen wird.

Die Rolle von Führung

Führung ist nicht außerhalb des Systems. Sie ist Teil des Systems.

Wenn ein Bereichsleiter jeden Sprint mit drei neuen Anforderungen direkt zum Team geht, signalisiert er: Der Prozess gilt für andere. Wenn eine Führungskraft Auslastung als Leistungsindikator benutzt, ermutigt sie das Team, beschäftigt zu wirken — nicht, zu liefern. Wenn Prioritätswechsel ohne strukturierte Entscheidung durchgeführt werden, ist das kein Anpassungsvermögen — es ist Priorisierungslosigkeit.

Das ist kein Vorwurf. Es ist ein strukturelles Muster. Führungskräfte wurden meist darauf trainiert, Ressourcenauslastung zu optimieren. In stabilen, planbaren Arbeitssystemen funktioniert das. In komplexen, wissensbasierten Kontexten führt es zu genau dem Bild, das oben beschrieben ist: viel Bewegung, wenig Output.

Was hilft: Eine Führungshaltung, die nach Ergebnis fragt, nicht nach Aktivität. Die Transparenz über das System zulässt. Und die Product Owner das Mandat gibt, tatsächlich zu priorisieren — und damit auch Nein zu sagen.

Warum Methoden allein nicht reichen

An dieser Stelle lohnt es sich, eine verbreitete Annahme zu hinterfragen: „Wir haben Scrum eingeführt — das sollte doch reichen."

Scrum oder Kanban sind Frameworks. Sie schaffen Sichtbarkeit und Rhythmus. Aber sie lösen keine Priorisierungsprobleme, die außerhalb des Teams entstehen. Sie lösen keine Führungsmuster, die Unterbrechungen und Parallelarbeit begünstigen. Und sie ersetzen keine Requirements-Engineering-Kompetenz.

Das ist keine Kritik an den Methoden. Es ist eine Einordnung: Frameworks sind Werkzeuge. Sie funktionieren, wenn die Rahmenbedingungen stimmen. Wenn sie nicht stimmen, sieht man das beschriebene Muster: Das Framework wird durchgeführt, aber die Wirkung bleibt aus. Was sich ändern muss, ist das System — nicht das Framework.

Erste Schritte aus der Beschäftigungsfalle

Es gibt keine universelle Lösung. Aber es gibt Muster, die häufig helfen:

• WIP-Beschränkung bewusst einführen. Ein Team, das pro Person maximal zwei parallele Aufgaben hält, wird schneller fertig — auch wenn das zunächst ungewohnt ist. Das Unbehagen, Arbeit nicht sofort anzufangen, ist ein gutes Zeichen.
• Backlog-Realismus herstellen. Welche Stories sind wirklich entscheidungsreif? Welche Anforderungen sind noch unklar und gehören nicht in den nächsten Sprint? Dieser Filter kostet einmalig Zeit — spart aber wiederholt Klärungs-Schleifen im Sprint.
• Lagebild herstellen. Was hat das Team in den letzten drei Sprints wirklich geliefert? Nicht was war in Arbeit — was ist fertig? Diese Frage ist unbequem. Sie ist notwendig.
• Führung in die Systemperspektive einbeziehen. Das Muster lässt sich nicht allein im Team lösen, wenn Führungsverhalten und Priorisierungsdisziplin außerhalb des Teams das Problem erzeugen.

Was strukturierte Diagnose leistet

Häufig liegt der Engpass nicht dort, wo man ihn vermutet. Teams vermuten, dass das Problem im Refinement liegt. Die Analyse zeigt, dass Product Owner kein Entscheidungsmandat haben. Führung vermutet, dass das Team ineffizient arbeitet. Die Analyse zeigt, dass Prioritätswechsel die eigentliche Ursache sind.

Eine strukturierte Agile Maturity Analysis hilft, die wirklichen Blockaden sichtbar zu machen — durch Interviews, Beobachtungen und die systematische Auswertung von Arbeitsmustern. Das Ergebnis ist kein Bewertungsformular, sondern ein Lagebild mit konkreten nächsten Schritten.

Das Muster „beschäftigt, aber wenig geliefert" ist lösbar. Aber nur, wenn man das System versteht, das es erzeugt.