
5 Gründe, warum Scrum nicht funktioniert
Mit Scrum sind wir noch langsamer“
„Ich sitze nur noch in Meetings und habe keine Zeit mehr, mich um Qualität zu kümmern“,
„Mit Scrum haben wir mehr Bugs als zuvor“.
Kommt dir das bekannt vor?
Wir bekommen diese Aussagen immer öfter auch von Unternehmen zu hören, die den Scrum Prozess scheinbar korrekt eingeführt haben. Aber woran liegt das? Bewirkt Scrum nicht eigentlich mehr Effizienz und Qualität?
Wir sind den Ursachen auf den Grund gegangen. In unserer Blog-Reihe Do Better Scrum decken wir auf, wieso Scrum scheitert, und wie du es besser machen kannst. Wir zeigen dir die Lücken im Scrum Guide und sprechen uns für eine ganzheitliche Betrachtung der agilen Entwicklung aus. Für mehr Fokus auf die Softwarequalität.
Du möchtest hochqualitative Software effizienter entwickeln? Dann lies weiter!
Darum scheitert dein Team an Scrum
Stell dir vor, ihr habt im Unternehmen Scrum als agile Arbeitsweise eingeführt. Dein Team hat sehr viel Zeit und Kraft investiert, um den Prozess erfolgreich zu etablieren.
Die Werte sowie Prinzipien habt ihr durchgesetzt und obwohl ihr den Scrum Guide bis ins kleinste Detail befolgt, bleiben die erhofften Ergebnisse aus. Ihr habt sogar eher das Gefühl, langsamer zu arbeiten und mehr Bugs zu produzieren. Das lässt euch zweifeln. Ihr fragt euch, was ihr falsch macht und ob Scrum wirklich das Richtige für euch ist?
Agilität ist seit 10 Jahren der De-facto-Standard in der Softwareentwicklung. Fast jedes Unternehmen stellt sich die Frage, wie es effizienter arbeiten kann. Die erste Wahl fällt meist auf Scrum. Unternehmen führen die agile Methode erfolgreich ein, aber die erhofften Vorteile wie höhere Effizienz und bessere Qualität können sie nicht erzielen.
Unserer Erfahrung nach tauchen immer die gleichen Verhaltensmuster oder Fehler auf, wenn Unternehmen Scrum einführen. Die häufigsten Stolpersteine haben wir für dich zusammengefasst.

Scrum ist falsch abgebogen. Der Fokus liegt zu sehr auf dem Prozess, als auf dem Handwerklichen. Deshalb setzen wir auf einen ganzheitlichen Ansatz.
5 Gründe, warum Scrum nicht funktioniert
1. Der Product Owner weiß nicht wohin
Wenn der Product Owner nicht weiß, wo es lang geht, wer dann? Die Aufgabe des Product Owners ist es, die Richtung vorzugeben. Die Produktvision sowie die Bedürfnisse der Nutzer:innen hat er dabei stets vor Augen. (Die 6 wichtigsten Aufgaben eines PO haben wir hier zusammengefasst)
Auch wenn die Entwickler:innen mal anderer Meinung sind, kann er seinen Standpunkt durchsetzen. Denn der Product Owner ist dafür verantwortlich, dass der Nutzen der Software für die Stakeholder stets im Mittelpunkt steht – und gleichzeitig eine Priorisierung der Interessen vornimmt, damit der Weg für das Scrum Team erkennbar bleibt.
Kann er diese Rolle nicht entsprechend ausführen, weil ihm z.B. das Wissen fehlt, so steht Scrum auf verlorenem Posten. Das Team plantscht wie ein Boot ohne Segel im offenen Meer herum.

Wichtig: Es geht es uns nicht darum, einzelne Personen für das Scheitern des Teams verantwortlich zu machen. Sondern das Verhalten im Hinblick auf das System zu hinterfragen. Es wird wahrscheinlich gute Gründe geben, warum sich eine Person im Team so verhält, wie sie es tut.
Ein ehemaliger Projektmanager fällt als Scrum Master schnell in alte Muster, wenn er von seinem Vorgesetzten Druck bekommt. Ein Product Owner spezifiziert Features falsch, weil ihm wichtige Informationen fehlen. Entwickler:innen gehen nicht auf die Vorschläge des Product Owners ein, weil sie sich nicht wertgeschätzt fühlen. Diese und viele weitere Ursachen gilt es aufzudecken.
2. Die Entwickler haben Scheuklappen auf
Wenn Entwickler:innen im Team ihr eigenes Ding durchziehen, bringt auch Scrum nichts. Scrum funktioniert nur, wenn alle im Team die Produktvision im Blick halten, Abhängigkeiten erkennen und Interessen der Nutzer:innen berücksichtigen. Transparent kommunizieren und offen für die Vorschläge und Bedenken der Anderen sein. Die Zusammenarbeit muss stimmen.
Wenn Entwickler:innen sich im Alleingang versuchen oder immer nur die Aufgaben erledigen wollen, die Ihnen am meisten Spaß machen, dann wird das schnell auf die Stimmung im Team schlagen.
Daher ist die Retrospektive auch ein zentrales Element in Scrum. Im Meeting reflektiert das Team die Zusammenarbeit, findet gemeinsam effiziente Lösungen und klärt Missverständnisse (Ideen für kreative Retro-Meetings haben wir hier gesammelt)
Sicherlich ist das ein Punkt, der dir bereits bekannt ist. Allerdings treten Unstimmigkeiten oder Alleingänge häufiger auf als viele denken - und das auch auf subtile Weise. Hier ist die Arbeit des Scrum Masters gefragt. Er beobachtet das Team und reflektiert deren Verhalten. Womit wir auch schon zum nächsten Punkt kommen.

3. Scrum Master=Projektmanager
Die Rolle des Scrum Masters wird häufig unterschätzt. Für viele ist es immer noch abstrus, dass die Aufgaben eines Scrum Masters einen ganzen Arbeitstag füllen sollen. Daher übernimmt in vielen Teams entweder ein anderes Teammitglied die Aufgaben des Scrum Masters oder ein klassischer Projektmanager setzt sich den Hut auf. (Lies hier, wie dein Weg zum Scrum Master aussehen kann)
Beide Optionen sind nicht empfehlenswert. Denn Projektmanager agieren oft nicht wie Scrum Master. Sie delegieren Aufgaben an das Entwicklungsteam, treffen eigenständig Entscheidungen und steuern das Projekt.
Ein Scrum Master hingegen unterstützt das Team dabei, diese Dinge selbst zu tun. Er deckt die Schwachstellen im Prozess auf, regt das Team zum Nachdenken an, steht bei der Lösungsfindung und Konfliktbewältigung zur Seite.
Und das geht nur, wenn der Scrum Master unabhängig ist. Daher kann er nicht gleichzeitig Entwickler:in oder Product Owner sein. Zumindest nicht am Anfang. Später, wenn sich das Team eingespielt hat, kann die Rolle des Scrum Masters in den Hintergrund rücken.
4. Fokus auf Prozess statt auf Qualität
Scrum ist an sich ein super Framework. Was im Scrum Guide allerdings nicht definiert ist, sind relevante technische Praktiken.
Bei der Einführung von Scrum konzentrieren sich die Entwickler:innen daher häufig auf den Prozess, vernachlässigen dabei das technische Handwerk. Dies ist allerdings erforderlich, um die Qualität der Software sicherzustellen.
Und das wiederum ist notwendig, damit Scrum seine volle Wirkung entfalten kann. Denn die kurz getakteten Zyklen in Scrum lassen keine langen Qualitätssicherungsphasen zu. Steigen die technischen Schulden immer weiter an, so kann die Qualität sinken, bis die technischen Schulden keinen weiteren Sprint mehr zulassen.
Flaccid Scrum - Das schwarze Loch in Scrum
Martin Flower, einer der Begründer der agilen Softwareentwicklung, nennt dieses Phänomen „Flaccid Scrum“, das schwache Scrum. Im Gegensatz zum Extreme Programming sind im Scrum Guide keine genauen Praktiken zur Entwicklung der Software beschrieben. Der Schwerpunkt liegt auf dem Vorgehen.
Damit bleibt in einem Scrum-Projekt ein großer Spielraum für Antipatterns (=ungünstige Verhaltensmuster), welche sich negativ auf die Qualität der Softwareentwicklung auswirken.
Good to know: Extreme Programming (=XP) ist ein agiles Framework, das von den drei Mitunterzeichnern des Agilen Manifests ins Leben gerufen wurde: Kent Beck, Ward Cunningham und Ron Jeffries. Kent Beck beschreibt in seinem Buch "Extreme Programming Explained" die Vorgehensweise und Prinzipien von XP.
5. Lange oder fehlende Feedbackzyklen
Die Entwickler:innen sind darauf angewiesen, dass sie von Product Owner, Stakeholder und anderen Developern regelmäßig Feedback erhalten. Gelingt dies nicht, können sie ihre Arbeit nicht korrekt ausführen. Die Entwicklung kommt ins Stocken, die Qualität des Codes leidet und es fallen nachträglich aufwendige Korrekturen an.
Im Scrum Prozess sind einige Feedbackschleifen integriert. Das Review oder Daily-Stand-up sind aber nicht ausreichend, um die Entwickler:innen mit genügend Input zu versorgen. Denn sie brauchen ein konstantes Feedback zu ihrem Produkt.
Im XP ermöglichen Praktiken wie Pair Programming, Refactoring, Test Driven Development, Small Iterations und Continous Integration ein fast zeitgleiches Review. In der XP Feedback-Schleife sind zusätzliche Möglichkeiten mitsamt ihrer Feedbackdauer aufgeführt.
Pair Programming ist beispielsweise eine Methode, bei dem Entwickler:innen zu zweit oder in der Gruppe am gleichen Code schreiben. Warum diese Vorgehensweise effizient und eben keine Zeitverschwendung ist, erklären wir in einem weiteren Beitrag unserer Reihe Do Better Scrum.
Die Folgen: Schlechte Software, langsamer Prozess
So wirkt sich das Scheitern im Scrum auf dein Team und Projekt aus:
1. Die Qualität der Software lässt nach
Während der Sprints unterlaufen immer mehr Fehler. Die Anzahl der Bugs steigt, die Kundenzufriedenheit sinkt. Um dem entgegenzuwirken, bauen Unternehmen immer größere QA-Abteilungen auf. Die Software wird spät im Prozess und aufwendig getestet, um die Qualität sicherzustellen.
2. Die Entwicklung verlangsamt sich
Eng verknüpft mit dem ersten Punkt: Wenn mehr Bugs auftreten, sind Entwickler:innen zunehmend damit beschäftigt, ihre früheren Fehler auszubaden, statt neue Features zu entwickeln. Das Produkt kann nur langsam weiterentwickelt werden. Der gesamte Entwicklungsprozess wird ausgebremst. Ein Management, das Scrum ohnehin schon skeptisch gegenübersteht, fühlt sich in der Annahme bestätigt, dass Scrum nicht funktioniert. Der Scrum Prozess wird wieder abgeschafft und vielleicht sogar das ganze Thema Agilität auf Eis gelegt. Das kann für ein Unternehmen aber fatal sein, denn die agile Softwareentwicklung birgt viele Chancen.
Ursache und Symptome unterscheiden
Genauso wenig, wie Scrum alle Probleme der Softwareentwicklung löst, ist Scrum alleine ursächlich für deren Scheitern. Vielmehr ist es das iterative Vorgehen von Scrum, das zuvor verborgene Qualitätsprobleme sichtbar macht.
Abhilfe schafft hier eine zusätzliche Berücksichtigung weiterer XP-Praktiken, die direkt auf eine höhere Softwarequalität einzahlen. Sie schließen die Lücke, die in einem Flaccid Scrum entstanden sind.
Zwar wird die Anwendung zusätzlicher Praktiken zunächst als Mehraufwand wahrgenommen, gleichzeitig es ist deutlich lohnenswerter als die Investition in rein reaktive Maßnahmen, etwa dem Aufbau einer großen QA-Abteilung.

Teams, die Scrum und XP ganzheitlich anwenden, bleiben auch über längere Zeit leistungsfähig und liefern funktionierende Softwareprodukte für Ihre Stakeholder.
Das Gleiche gilt auch für das Verhalten im Team. Für den Erfolg von Scrum ist es unerlässlich, dass alle Teammitglieder ihre Funktionen und Aufgaben genaustens kennen. Denn als Scrum Master, Product Owner oder Developer gilt es einiges zu beachten. Die Zusammenarbeit ist eine andere, vor allem, wenn zuvor keine agilen Arbeitsweisen angewendet wurden. Es kann Zeit brauchen, bis sich die Kolleg:innen in ihren Rollen einfinden und sich das Team einspielt.
Die Lösung: Rollenverständnis und technische Praktiken
Damit Scrum nicht zum Scheitern verurteilt ist, solltest du zwei Aspekte besonders beachten: die Einbindung technischer Praktiken und das Rollenverständnis im Team. Scrum sollte nicht nur als ausgehöhlter Prozess angewandt, sondern mit technischen Praktiken gefüllt werden.
Alle im Team sollten ihre Rolle kennen und diese korrekt ausführen können. Im Extreme Programming gibt es viele Methoden, die die Codequalität erhöhen und sich mit Scrum gut kombinieren lassen. Auf diese Weise wird die Qualität der Software schon während des Sprints sichergestellt.
Die Effizienz des Teams steigt und siehe da - Scrum funktioniert.
Wie das im Detail geht, werden wir in unserer Blog-Reihe weiter ausführen. Folge uns gerne auf LinkedIn oder abonniere unseren Newsletter. So wirst du über die neusten Beiträge informiert.
In unserem nächsten Artikel unserer Reihe Do Better Scrum geht es um das Scrum Team. Wir stellen die wichtigsten Dos und Don’ts von Scrum Mastern, Product Ownern und Developer vor. Du erfährst, wie sich die Rollen richtig verhalten und Scrum vor dem Scheitern bewahren!
Du brauchst jetzt ein funktionierendes Scrum Team für deine Softwareentwicklung? Dann meld dich bei uns und lass dich kostenlos beraten!