Scrum vs. Realität: Warum Theorie und Praxis so weit auseinanderliegt

Auf dem Papier klingt Scrum erstaunlich einfach. Ein kleines Team arbeitet auf ein gemeinsames Produktziel hin. Es liefert regelmäßig nutzbare Ergebnisse, holt Feedback ein und verbessert seine Arbeitsweise. In der Realität sieht es oft anders aus. Product Owner dürfen nicht entscheiden. Scrum Master organisieren Meetings. Teams arbeiten gleichzeitig in mehreren Projekten. Das Daily wird zum Statusbericht und im Sprint Review wird präsentiert statt gelernt. Scrum vs. Realität: Warum Theorie und Praxis so weit auseinanderliegt, hat deshalb weniger mit dem Scrum Guide als mit Organisationen zu tun, die Scrum einführen, ohne Verantwortung, Entscheidungsrechte und Strukturen zu verändern. Wer Scrum verbessern will, muss genau dort ansetzen.

Scrum ist ein leichtgewichtiges Framework für komplexe Arbeit. Es basiert auf Empirie. Teams machen Arbeit und Ergebnisse transparent, überprüfen sie regelmäßig und passen ihr Vorgehen an neue Erkenntnisse an.

Der offizielle Scrum Guide ist bewusst kurz. Die derzeit aktuelle Fassung stammt weiterhin aus November 2020. Sie definiert drei Accountabilities, fünf Events, drei Artefakte und die dazugehörigen Commitments. Sie schreibt aber beispielsweise weder User Stories noch Story Points, Planning Poker oder Jira vor.

Die Praxis fügt häufig sehr viel hinzu.

Aus Scrum wird dann:

Formal arbeitet das Unternehmen weiterhin mit Scrum.

Inhaltlich existiert häufig ein anderes System.

Genau daraus entsteht die Lücke zwischen Scrum-Theorie und Scrum-Realität.

Viele Scrum-Einführungen beginnen mit dem Kalender.

Montag:

Sprint Planning.

Jeden Morgen:

Daily Scrum.

Freitag:

Review und Retrospektive.

Die Termine stehen.

Also arbeitet das Team jetzt agil.

Das ist einer der größten Irrtümer.

Scrum verändert nicht primär Meetings. Es verändert die Art, wie ein Team mit Verantwortung, Unsicherheit und Entscheidungen umgeht.

Der Scrum Guide verlangt unter anderem:

Fehlen diese Grundlagen, retten die Events das System nicht.

Scrum.org weist selbst darauf hin, dass verbreitete Praktiken häufig für Scrum gehalten werden, obwohl sie gar nicht Bestandteil des Frameworks sind. Dazu gehören etwa mechanisch verwendete drei Fragen im Daily oder Proxy Product Owner ohne echte Entscheidungsbefugnis.

Der Product Owner trägt die Verantwortung dafür, den Wert des Produkts zu maximieren und das Product Backlog wirksam zu managen.

Dafür braucht er echte Entscheidungsmöglichkeiten.

In vielen Unternehmen funktioniert die Rolle jedoch so:

Der Product Owner priorisiert.

Dann entscheidet:

noch einmal.

Oder alle gleichzeitig.

Der Product Owner wird damit zum Proxy.

Er verwaltet Anforderungen, besitzt aber keine ausreichende Produktverantwortung.

Scrum.org beschreibt genau dieses Muster als problematisch. Muss ein vermeintlicher Product Owner jede Produktentscheidung an eine andere Instanz weiterleiten, verlängert sich die Entscheidungskette und Feedback verliert Geschwindigkeit.

Kann der Product Owner tatsächlich entscheiden:

Wenn nicht, liegt kein Methodenproblem vor.

Es liegt ein Governance-Problem vor.

Scrum Teams sollen selbst entscheiden, wer was wann und wie bearbeitet.

Das bedeutet nicht Führungslosigkeit.

Es bedeutet, dass die Verantwortung für die operative Organisation der Arbeit im Team liegt.

Die Realität sieht häufig anders aus.

Ein Teamleiter weist Arbeit zu.

Der Projektleiter verfolgt Aufgaben.

Der Scrum Master fragt nach Fortschritt.

Der Product Owner setzt einzelne Entwickler auf dringende Tickets.

Das Team organisiert sich nicht selbst.

Es bekommt Arbeit organisiert.

Forschung zu agilen Transformationen zeigt, dass echte Autonomie nicht allein durch neue Rollen entsteht. In einer untersuchten großen öffentlichen Organisation mussten dafür unter anderem Produktverantwortung, Kompetenzen, Finanzierung und organisatorische Strukturen verändert werden. Erst dadurch konnte ein Team tatsächlich über Backlog und Arbeitsweise verfügen.

Das ist ein wichtiger Punkt.

Selbstmanagement kann man nicht per Organigramm anordnen.

Man muss die Bedingungen dafür schaffen.

Ein Sprint soll nicht einfach ein Zwei-Wochen-Container für Aufgaben sein.

Das Sprint Goal gibt dem Team einen gemeinsamen Zweck.

In der Praxis besteht ein Sprint Backlog jedoch häufig aus:

Alle arbeiten.

Aber woran arbeitet das Team gemeinsam?

Kann niemand erklären, was am Ende des Sprints als gemeinsamer Fortschritt erreicht werden soll, fehlt ein zentraler Orientierungspunkt.

Das erzeugt Folgen:

Scrum.org nennt fehlende gemeinsame Ziele und zufällig zusammengestellte Backlog Items ausdrücklich als typische Anti-Patterns.

Ein gutes Sprint Planning beantwortet deshalb nicht nur:

„Wie viel schaffen wir?“

Sondern:

„Was wollen wir in diesem Sprint gemeinsam erreichen?“

Das Daily Scrum gehört zu den sichtbarsten Beispielen für die Lücke zwischen Theorie und Realität.

Die klassische Praxis:

Jeder beantwortet nacheinander:

Der Scrum Master hört zu.

Manchmal nimmt zusätzlich ein Manager teil.

Das Ergebnis:

Alle haben ihren Status abgegeben.

Der Plan hat sich nicht verändert.

Der Scrum Guide schreibt dieses Format seit 2020 nicht mehr vor. Entscheidend ist vielmehr, dass die Developer den Fortschritt zum Sprint Goal prüfen und ihre bevorstehende Arbeit entsprechend anpassen.

Das Daily ist kein täglicher Rechenschaftstermin.

Ein besseres Daily fragt beispielsweise:

Der Unterschied wirkt klein.

In der Praxis verändert er das gesamte Meeting.

Ein Team erhöht seine Velocity.

Sehr schön.

Aber steigt dadurch auch der Produktwert?

Nicht zwingend.

Die Fixierung auf Story Points gehört zu den problematischsten Entwicklungen vieler Scrum-Umgebungen.

Teams werden daran gemessen:

Damit wird aus einer internen Planungshilfe schnell eine Leistungskennzahl.

Die Folge ist vorhersehbar.

Das System optimiert Output.

Nicht Outcome.

Ein Team kann 100 Story Points liefern und trotzdem eine Funktion entwickeln, die kaum jemand benötigt.

Das Product Backlog darf deshalb nicht einfach eine möglichst effiziente Abarbeitungsschlange werden.

Scrum.org weist bei Product-Owner-Anti-Patterns genau darauf hin: Ein großes Backlog oder hohe Aktivität führt nicht automatisch zu höherem Kundennutzen.

Die bessere Frage lautet:

„Was hat sich für Nutzer oder Unternehmen durch diesen Sprint verbessert?“

Freitag, 14 Uhr.

Das Team präsentiert seine Ergebnisse.

Der Product Owner sitzt vorne.

Stakeholder schauen zu.

Anschließend heißt es:

„Abgenommen.“

Das ist ein verbreitetes Muster.

Aber der eigentliche Zweck eines Sprint Reviews ist größer.

Das Team und relevante Stakeholder betrachten gemeinsam:

Das Review soll neue Informationen erzeugen.

Wenn das Backlog danach exakt so aussieht wie vorher, obwohl relevantes Feedback entstanden ist, wird ein zentraler Bestandteil der empirischen Arbeitsweise verschenkt.

Eine formale Produktabnahme durch den Product Owner ist im Scrum Framework so nicht vorgesehen. Scrum.org führt diese Interpretation ausdrücklich als Product-Owner-Anti-Pattern auf.

Ein gutes Review endet deshalb nicht mit:

„Gefällt euch das?“

Sondern mit:

„Was haben wir gelernt und was bedeutet das für unsere nächsten Entscheidungen?“

„Was lief gut?“

„Was lief schlecht?“

„Was können wir verbessern?“

Dann kleben zehn digitale Zettel auf einem Board.

Eine Maßnahme wird formuliert:

„Kommunikation verbessern.“

Nächster Sprint.

Genau so verlieren Retrospektiven ihre Glaubwürdigkeit.

Eine Retrospektive erzeugt nur dann Wert, wenn das Team seine Arbeitsweise tatsächlich verändern kann.

Dazu braucht es:

Noch wichtiger:

Manche Ursachen liegen außerhalb des Teams.

Beispielsweise:

Dann darf die Retrospektive nicht zum Ritual werden, bei dem das Team jeden zweiten Freitag Probleme aufschreibt, die es selbst gar nicht lösen kann.

Der Scrum Master muss solche Impediments auch auf organisatorischer Ebene adressieren.

Scrum geht von einem Team aus, das gemeinsam auf ein Ziel hinarbeitet.

In vielen Unternehmen gehört ein Spezialist aber gleichzeitig zu:

Auf dem Papier verfügt jedes Team über die benötigte Kompetenz.

Praktisch warten alle.

Scrum.org nennt die parallele Verteilung von Developern auf mehrere Projekte sogar als typisches Muster, das Teamproduktivität und Selbstmanagement untergräbt.

Das Problem ist nicht Scrum.

Es ist Ressourcenzuteilung.

Ein Team kann nur begrenzt selbstmanagen, wenn wesentliche Teile seiner Kapazität permanent von außen umpriorisiert werden.

Eine wissenschaftlich untersuchte große öffentliche Organisation wollte ihre Softwareentwicklung stärker agil und eigenständig gestalten.

Zu Beginn vermittelte ein internes Team im Wesentlichen zwischen Fachseite und externen Dienstleistern.

Echte Produktverantwortung lag verteilt.

Im Laufe der Transformation änderte die Organisation mehrere strukturelle Bedingungen:

Erst dadurch entstand ein tatsächlich autonomeres Produktteam.

Die Forschenden stellten fest, dass Teamautonomie eben nicht nur eine Frage agiler Praktiken war. Organisationsstruktur und Finanzierung mussten mitverändert werden.

Das Beispiel zeigt:

Scrum kann organisatorische Probleme sichtbar machen. Es kann sie aber nicht allein beseitigen.

Eine weitere wissenschaftliche Fallstudie begleitete eine agile Transformation über ein Jahr.

Befragt wurden unter anderem Entwickler, Tester, Architekten, Product Owner, Scrum Master und Führungskräfte.

Dabei zeigte sich:

Die Einführung agiler Rollen und neuer Verantwortlichkeiten erzeugte nicht automatisch Klarheit.

Mitarbeitende mussten gleichzeitig:

Die Transformation veränderte damit nicht nur Prozesse, sondern Identität, Verantwortung und Zusammenarbeit.

Genau deshalb unterschätzen Unternehmen Scrum-Einführungen häufig.

Man führt nicht nur Events ein.

Man verschiebt Verantwortung.

Remote Work wurde zeitweise als Ursache dafür genannt, dass Scrum nicht mehr richtig funktioniere.

Eine 2025 veröffentlichte Action-Research-Studie untersuchte genau diese Frage in einem großen internationalen Softwareumfeld.

Das interessante Ergebnis:

Nur wenige der dauerhaft beobachteten Probleme ließen sich tatsächlich auf Remote Work zurückführen.

Die Mehrzahl entstand durch mangelhafte Scrum-Implementierung.

Die Forschenden fanden außerdem, dass Remote-Teams stärker von gezielter Dokumentation und kontextangepassten Scrum-Praktiken profitieren können.

Remote Scrum ist damit nicht grundsätzlich das Problem.

Remote Work macht manche bereits vorhandenen Schwächen lediglich sichtbarer.

Der Fachbereich arbeitet weiterhin über Anforderungen und Übergaben.

Er wird zum Backlog-Verwalter.

Statt Team und Organisation weiterzuentwickeln.

Analyse, Entwicklung und Test arbeiten weiterhin nacheinander.

Woche eins Analyse.

Danach Entwicklung.

Am Ende Test.

Dadurch verliert die Kennzahl ihren Nutzen für die Teamplanung.

Probleme wiederholen sich Sprint für Sprint.

Echte Produktzusammenarbeit findet kaum statt.

Scrum.org warnt vor übergroßen Backlogs, die Transparenz und Produktfokus verschlechtern.

Das Team entscheidet schnell.

Die Organisation entscheidet langsam.

Scrum ist kein universeller Ansatz.

Es passt schlecht, wenn:

Scrum funktioniert ebenfalls schlecht, wenn Unternehmen gleichzeitig erwarten:

Das ist kein Scrum-Problem.

Das ist ein widersprüchliches Steuerungsmodell.

In solchen Situationen kann ein klassischer oder hybrider Ansatz sinnvoller sein.

Wer wissen möchte, ob Scrum nur formal oder tatsächlich funktioniert, sollte zehn Fragen beantworten:

Mehrere Nein-Antworten sind ein deutliches Signal.

Das Unternehmen braucht dann wahrscheinlich nicht mehr Scrum-Schulungen.

Es muss die Rahmenbedingungen überprüfen.

Liste auf, was die Organisation verlangt.

Dann unterscheide:

Dokumentiere ausdrücklich:

Reduziere parallele Projektzuordnungen und ständigen Personalwechsel.

Ein Sprint sollte mehr sein als ein Behälter für einzelne Tickets.

Aus relevantem Feedback muss eine sichtbare Konsequenz entstehen können.

Nicht jedes Impediment liegt im Team.

Der Scrum Master muss organisatorische Muster sichtbar machen und deren Veränderung unterstützen.

Ergänze Outputmetriken durch:

Scrum verlangt Inspektion und Anpassung.

Das sollte auch für die eigene Scrum-Anwendung gelten.

Frage regelmäßig:

Welcher Bestandteil unserer Arbeitsweise erzeugt tatsächlich Wert und wo sabotieren unsere Organisationsstrukturen das Framework?

Wenn Scrum schlecht funktioniert, lautet die Reaktion häufig:

„Wir müssen Scrum konsequenter machen.“

Das kann richtig sein.

Muss es aber nicht.

Manchmal zeigt die Analyse:

Professionalität bedeutet nicht, Scrum um jeden Preis zu retten.

Sie bedeutet, die passende Arbeitsweise für das Problem zu wählen.

Häufig fehlen Voraussetzungen wie echte Product-Owner-Verantwortung, stabile Teams, Selbstmanagement und schnelle Feedback- und Entscheidungswege. Scrum macht diese organisatorischen Schwächen oft stärker sichtbar.

Viele Unternehmen ergänzen Scrum um eigene Rollen, Prozesse und Freigaben. Das kann sinnvoll sein. Werden jedoch Kernelemente verändert oder entfernt, kann die Wirksamkeit des Frameworks stark sinken. Darauf weist der offizielle Scrum Guide ausdrücklich hin.

Ein Scrum Anti-Pattern ist ein wiederkehrendes Verhalten, das zunächst sinnvoll erscheinen kann, aber Empirie, Selbstmanagement oder Wertschöpfung behindert. Typische Beispiele sind Daily-Statusberichte, Proxy Product Owner oder übergroße Backlogs.

Weil Organisationen zwar die Rolle einführen, bestehende Entscheidungsstrukturen aber unverändert lassen. Der Product Owner verwaltet dann Prioritäten, während andere Instanzen tatsächlich entscheiden.

Grundsätzlich ja. Mit zunehmender Größe wachsen jedoch Abhängigkeiten, Governance- und Koordinationsbedarf. Empirische Studien großer Transformationen zeigen, dass Rollen, Entscheidungswege und organisatorische Strukturen deshalb mit angepasst werden müssen.

Ja. Eine 2025 veröffentlichte Untersuchung kam zu dem Ergebnis, dass viele Probleme in Remote-Scrum-Teams eher aus einer mangelhaften Umsetzung als aus der räumlichen Distanz selbst entstanden. Gute Dokumentation und angepasste Zusammenarbeit gewinnen remote jedoch an Bedeutung.

Scrum und Realität liegen nicht deshalb weit auseinander, weil der Scrum Guide zu theoretisch wäre.

Die größere Ursache liegt häufig darin, dass Unternehmen das sichtbare Framework übernehmen, aber das dahinterliegende Organisationsmodell nicht.

Events werden eingeführt.

Entscheidungsrechte bleiben bestehen.

Rollen werden umbenannt.

Hierarchien greifen weiterhin operativ ein.

Teams sollen sich selbst managen.

Ihre Mitglieder werden gleichzeitig auf mehrere Projekte verteilt.

Product Owner sollen Wert maximieren.

Über Prioritäten entscheiden andere.

Retrospektiven sollen Verbesserung schaffen.

Die wichtigsten Hindernisse darf das Team aber nicht verändern.

Dann entsteht Scrum-Theater.

Die Lösung ist nicht noch mehr Methodentreue.

Entscheidend ist, die grundlegende Logik ernst zu nehmen:

klare Ziele, echte Verantwortung, kurze Feedbackschleifen, Transparenz und die Fähigkeit, auf neue Erkenntnisse tatsächlich zu reagieren.

Wenn eine Organisation diese Bedingungen schafft, braucht sie Scrum nicht perfekt nachzuspielen.

Scrum beginnt dann zu funktionieren.

Und wenn diese Bedingungen nicht geschaffen werden können oder Scrum nicht zum Arbeitskontext passt, ist es professioneller, einen anderen Ansatz zu wählen, statt jahrelang schlechte Scrum-Praxis als „Agile Transformation“ zu verkaufen.

PURE Consultant unterstützt Unternehmen dabei, Scrum nicht nur formal einzuführen, sondern Rollen, Entscheidungswege und Zusammenarbeit so auszurichten, dass agile Teams tatsächlich selbstständig arbeiten, lernen und messbaren Wert erzeugen können.