Darf man die heilige Kuh Scrum kritisieren?

Dieser Artikel soll absolut kein Scrum-Bashing werden, sondern ein vernünftiger Diskurs, der die Argumente beider Seiten analysiert und diskutiert.

Durch meine tägliche Arbeit, bin ich gerade mit vielen Tätigkeitsfeldern und verschiedenen Planungen in den letzten 20 Jahren in Berührung gekommen.

Man muss Scrum beurteilen als sei es ein böser Zwilling. Scrum ist eben nur ein Framework (und ja mehr ist es nun wirklich nicht!) zeigt deinem Team nur was eben nicht funktioniert, die Lösungen müsst ihr immer selber finden. Und nur IHR (also dein Team) müsst dafür Sorge tragen das Scrum mit Leben gefüllt wird.

Solange man, die nicht zu übersehenden Probleme immer wieder ignoriert oder nur rudimentäre Maßnahmen ergreifen will, genau solange wird Scrum für euch keinerlei Mehrwehrt einbringen.

Ganz einfach: Scrum löst keine Probleme und wird es auch nie machen. Wenn Du mit einem Wagen ohne Bremse auf eine Klippe zuhältst, wird Scrum Dir dabei helfen den Abhang schneller zu erreichen. Die Bremsen musst du dann aber noch während der Fahrt selber reparieren.

Analysieren wir aber als erstes Mal die Nachteile von Scrum:

Nachteile von Scrum

Die Koordination mehrerer Scrum-Teams kann schierig sein (Stichwort “Scrum of Scrums”)
Die Erwartungshaltung an Scrum ist oft unrealistisch: “Scrum löst alle Probleme”
Scrum ist einfach und daher auch in vielen Stellen unklar, bzw. gibt wenig konkrete Handlungsempfehlungen.
Kein Gesamtüberblick über die komplette Projektstrecke
Hoher Kommunikations- und Abstimmungsaufwand
Wenige konkrete Handlungsempfehlungen
Zeitverluste bei zu „defensiven" Sprintplanungen
„Tunnelblick-Gefahr" bei ausschließlicher Fokussierung auf Tasks
Erschwerte Koordination mehrerer Entwicklungsteams bei Großprojekten
Potenzielle Verunsicherung aufgrund fehlender Zuständigkeiten und Hierarchien
Potenzielle Unvereinbarkeit mit bestehenden Unternehmensstrukturen

Agile Anti-Patterns from Mayflower GmbH

Weitere Probleme die durch den Einsatz von Scrum

Scrum und Test

Akzeptanztests in Scrum-Projekten: Theorie und Praxis

Vorteile von Scrum

Der Erfolg des agilen Manifests liegt nicht zuletzt darin begründet, dass die darin formulierten Grundsätze klar verständlich und für viele nachvollziehbar sind. So wird Individuen und Interaktionen der Vorrang über Prozesse und Werkzeuge eingeräumt, funktionierende Software zählt mehr als umfassende Dokumentation, Zusammenarbeit mit dem Kunden erhält Vorfahrt gegenüber Vertragsverhandlungen und das Reagieren auf Veränderungen wird höher eingeschätzt als das Befolgen eines vorab festgelegten Plans.

So weit, so gut?

Wenige Regeln, leicht verständlich und schnell einführbar
Kurze Kommunikationswege
Hohe Flexibilität/Agilität durch adaptives Planen
Hohe Effektivität durch Selbstorganisation
Hohe Transparenz durch regelmäßige Meetings und Backlogs
Zeitnahe Realisation neuer Produkteigenschaften bzw. Inkremente
Kontinuierlicher Verbesserungsprozess
Kurzfristige Problem-Identifikation
Geringer Administrations- und Dokumentationsaufwand
Risiken und Probleme werden transparen.
Höhere Flexibiliät bei Anforderungsänderungen oder unerwarteten Problemen.
Weniger Dokumentationsaufwand. Anforderungsdefinition aus Usersicht in Form von User Stories.
Hohe Kundenorientierung durch schnelles Nutzerfeedback.

Grundsätzlich ist Scrum als Framework natürlich für viele Projekte die richtige Lösung und bietet vielfach die passende Lösung. Grundsätzlich aber wie man den Nachteilen auch entnehmen kann, ist Scrum manchmal auch der Störfaktor der vorher gut laufende Entwicklungsprojekte durch seine Integration in den Entwicklungsprozess gestört hat.
Ein ganz wichtiger Punkt, Scrum macht als Framework das was es soll, die Einführung in eine bestehende Prozessstruktur kann aber ewig dauern.

Nehmen wir hier das Beispiel: Wasserfallprozess wird auf Scrum umgestellt, während der Umstellung wird (meistens überraschend“) festgestellt das bestimmte Prozesse eben nicht auf Scrum umgestellt werden können. Hier nenne ich bewusst mal die Hardwareherstellung, denn genau diese Problematiken sind dort bekannt. Vielfach wurden hier bis 6 Monate Test gefahren, aus gutem Grund.

Worüber man bei der Einführung von Scrum nie nachdenkt, ist die Tragweite aller bestehenden Prozesse. Man kann Scrum nicht von heute auf morgen einführen. Entweder ich mache das schon in der direkten Planung, oder aber ich bin mir bewusst, dass ich einen bestehenden Prozess klar in Chaos führe. Und diese Umstellungen kosten maximal viel Zeit.

Auf folgende Artikel habe ich mich bezogen:

https://www.linkedin.com/pulse/agile-dead-matthew-kern

http://rubiquity.com/2014/03/12/agile-is-dead-angry-developer.html

http://www.williamedmondson.com/agile-dead/

http://techbeacon.com/agile-manifesto-dead

https://dzone.com/articles/coconut-headphones-why-agile

https://madebymany.com/blog/the-more-you-try-and-practice-agile-the-less-agile-you-become-and-vice-versa

http://habitsanddesign.com/2016/02/08/agile-is-dead/

http://kristopherwilson.com/2015/03/09/the-daily-stand-up-is-an-antipattern/

http://www.daedtech.com/agile-false-hope-and-real-promise/

https://pragdave.me/blog/2014/03/04/time-to-kill-agile/

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/