Woran man merkt, dass die Produktentwicklung klemmt

Wenn die Produktentwicklung ins Stocken gerät, kündigt sich das selten mit einem lauten Knall an. Kaum ein Projekt implodiert von heute auf morgen, und meistens gibt es auch nicht den einen Sündenbock, auf den alle zeigen können. Viel häufiger sind es die kleinen, leisen Signale im Alltag. Sie sammeln sich über Wochen an, bis irgendwann nur noch dieses eine Gefühl bleibt: Wir bewegen uns zwar ständig, kommen aber nicht vom Fleck.

Ein Bild aus meiner eigenen Laufbahn lässt mich bis heute nicht los. Nach außen hin war die Stimmung im Team tadellos. Alle gingen ausgesprochen nett miteinander um, doch in jedem Meeting brodelte es unter der Oberfläche. Es gab reichlich Flurfunk, man beschwerte sich im Zweiergespräch immer wieder über dieselben Dinge – aber niemand legte diese Punkte dort auf den Tisch, wo sie hingehört hätten: in die Retrospektive. Vor Jahren habe ich für genau diesen Zustand einen treffenden Begriff aufgeschnappt: Friedhöflichkeit.

Solche Signale wirken von außen harmlos. Genau das macht sie so gefährlich. Ein Team gewöhnt sich an sie, hält sie irgendwann für normal und verlernt, sie als Warnzeichen wahrzunehmen. Fünf dieser Symptome begegnen mir besonders häufig. Da jedes einzelne eine tiefere Analyse verdient, starten wir in diesem Artikel mit dem Überblick.

1. Wenn die Sprintplanung nie aufgeht

Das offensichtlichste Symptom ist auch das messbarste: Was geplant wird, wird nicht fertig. Ein Sprint nach dem anderen endet damit, dass Tickets in den nächsten geschoben werden. Mit jeder Runde sinkt das Vertrauen, dass eine Planung überhaupt irgendeinen Wert hat.

Das liegt meistens gar nicht daran, dass das Team zu langsam arbeitet, sondern kann viele unterschiedliche Ursachen haben: Vielleicht ist die Schätzung falsch, vielleicht werden Abwesenheiten nicht eingeplant, vielleicht hat das Team ständig mit Incidents und Bugs zu kämpfen oder vielleicht liegt es auch daran, dass niemand genau sagen kann, worauf der Sprint eigentlich einzahlt.

Der Scrum Guide (in der Fassung von 2020) hat diesem Problem entgegengewirkt, indem er neben dem Was und dem Wie ausdrücklich nach dem Warum fragt. Das Sprint Goal steht hier als verbindliches Ziel im Mittelpunkt. Entscheidend ist: Dieses Ziel beschreibt ein konkretes Ergebnis, nicht das reine Abarbeiten von Aufgaben. Fehlt diese Klammer, zerfällt der Sprint in eine leblose Liste unverbundener Tickets und niemand weiß, worauf eigentlich gerade hingearbeitet wird.

2. Wenn viel entsteht, aber nichts bewirkt wird

Das zweite Symptom ist unbequemer, weil es sich hinter scheinbarer Produktivität versteckt. Das Team liefert ab, die Velocity stimmt, Feature um Feature geht live – und trotzdem verändert sich beim Kunden oder Nutzer absolut nichts.

Melissa Perri hat dafür den Begriff der Build Trap geprägt: die Falle, in der eine Organisation ihren Erfolg nur noch an der Menge der gebauten Dinge misst, statt an deren tatsächlicher Wirkung.

Es ist der klassische Unterschied zwischen Output und Outcome. Josh Seiden definiert Outcome sehr elegant als eine Veränderung im Verhalten von Menschen, die zu geschäftlichem Erfolg führt. Ein ausgeliefertes Feature ist reiner Output. Ob die Nutzer dadurch ihr Verhalten ändern oder ein Problem gelöst bekommen, ist der Outcome. Wer nur den Output zählt, kann monatelang hochbeschäftigt sein und am Ende feststellen, dass sich am eigentlichen Problem kein Millimeter bewegt hat.

3. Wenn alle nett sind, aber geschwiegen wird

Damit sind wir zurück bei der Friedhöflichkeit. Ein Team, das betont harmonisch auftritt, wirkt auf den ersten Blick gesund. Doch entscheidend für den Erfolg ist nicht, ob wir nett zueinander sind, sondern ob wir die unbequemen Dinge ansprechen können. Wenn Kritik nur hinter vorgehaltener Hand geäußert wird und die Retrospektive zur Pflichtübung verkommt, fehlt dem Team die wichtigste Grundlage, um besser zu werden.

In der Fachwelt nennen wir das "psychologische Sicherheit". Amy Edmondson beschrieb das schon 1999 als die gemeinsame Überzeugung eines Teams, dass es sicher ist, zwischenmenschliche Risiken einzugehen.

• Wichtig dabei: Psychologische Sicherheit bedeutet explizit nicht, dass immer alles harmonisch und kuschelig sein muss. Es bedeutet die Gewissheit, dass niemand bloßgestellt oder abgestraft wird, wenn er einen wunden Punkt anfasst.
• Wie erfolgskritisch das ist, zeigte später Googles Project Aristotle: Bei der Analyse von rund 180 Teams stellte sich psychologische Sicherheit als der mit Abstand wichtigste Faktor für effektive Zusammenarbeit heraus. Friedhöflichkeit ist also kein kosmetisches Stimmungsproblem, sondern ein echtes Alarmsignal.

4. Wenn niemand in einem Satz erklären kann, woran gerade gearbeitet wird

Dieses Symptom lässt sich mit einer einzigen Frage aufdecken. Frag den Product Owner oder das Team, woran gerade gearbeitet wird. Wenn die Antwort kein klarer Satz ist, sondern ein fünfminütiger Monolog, sollten die Alarmglocken schrillen.

Das ist fast nie ein Zeichen von Inkompetenz, sondern von mangelndem Fokus. Es wurden einfach zu viele Dinge gleichzeitig angefangen, sodass die klare Richtung verloren ging.

Nicht ohne Grund ist Fokus einer der Kernwerte von Scrum. Je mehr Aufgaben parallel offen sind, desto mehr Energie verpufft im Context Switching (dem ständigen Wechseln zwischen Aufgaben) und desto weniger echter Fortschritt entsteht. Wer seine Arbeit nicht in einem prägnanten Satz zusammenfassen kann, hat meistens nicht zu wenig getan, sondern zu viel auf einmal.

5. Wenn echtes Nutzerfeedback durch die Meinung des Chefs ersetzt wird

Dieses Symptom versteckt sich oft hinter vermeintlich strategischen Entscheidungen. Das Team entwickelt fleißig ein Feature nach dem anderen, hat aber seit Monaten kein direktes Feedback von echten Nutzer:innen mehr gehört. Stattdessen werden Prioritäten danach gesetzt, wer im Raum am lautesten argumentiert – oder am besten bezahlt wird.

In der Produktwelt gibt es dafür ein treffendes Akronym: das HiPPO-Prinzip (Highest Paid Person’s Opinion). Wenn valide Daten und echtes Kundenfeedback fehlen, füllt die Meinung der hierarchisch höchsten Person das Vakuum.

Dies ist aus zweifacher Sicht problematisch: Zum einen baut man am Markt vorbei, zum anderen entzieht es dem Team die intrinsische Motivation. Die meisten Entwickler:innen wollen Probleme lösen, nicht bloß Spezifikationen "vom Band" abarbeiten. Wenn der direkte Draht zum Kunden abreißt, mutiert die Produktentwicklung zur reinen Feature-Fabrik für interne Stakeholder.

Warum der Blick von außen so schwerfällt

Diese fünf Symptome haben eine Gemeinsamkeit: Sie zeigen sich an der Oberfläche, aber ihre Ursachen liegen tief im System. Genau deshalb sind sie für das Team selbst so schwer zu erkennen. Wenn man jeden Tag in derselben Dynamik steckt, gewöhnt man sich an die gerissenen Sprints, an die freundliche Sprachlosigkeit, an den Feature-Ausstoß ohne Wirkung und an die Entscheidungen von oben.

Meistens braucht es einen Impuls von außen oder zumindest einen bewussten Schritt zurück, um diese Signale wieder richtig deuten zu können.

Jedes dieser fünf Themen verdient eine eigene, tiefere Betrachtung – und genau darum wird es in den nächsten Beiträgen gehen. Für den Anfang reicht die Erkenntnis: Eine klemmende Produktentwicklung kündigt sich fast immer frühzeitig an. Wir müssen nur lernen, die leisen Zeichen ernst zu nehmen.

---

Quellen

• Schwaber, K. & Sutherland, J. (2020): "The Scrum Guide". Sprint Goal, Product Goal und der Wert Fokus, scrumguides.org.
• Perri, M. (2018): "Escaping the Build Trap: How Effective Product Management Creates Real Value". Output gegen Outcome, O'Reilly.
• Seiden, J. (2019): "Outcomes Over Output". Definition eines Outcome als Verhaltensänderung, Buchüberblick.
• Edmondson, A. (1999): "Psychological Safety and Learning Behavior in Work Teams". Administrative Science Quarterly, 44(2), S. 350–383, SAGE Journals. Weiterführend: Edmondson, A. (2018): "The Fearless Organization".
• Google re:Work / Project Aristotle: Psychologische Sicherheit als wichtigster Faktor effektiver Teams, Understand team effectiveness.