“Wir haben uns bewusst gegen Scrum entschieden…”.
“Wir haben Scrum wieder abgeschafft…”.
“Wir haben uns vom Scrum Master getrennt. Der wollte immer ‘Scrum by the book’…”.

2019 habe ich in einer Agentur Scrum eingeführt und bin bei vielen Entwicklern anfangs auf heftigen Widerstand gestoßen.

Was steckt dahinter? Warum ist Scrum in vielen Umgebungen erfolgreich, in anderen nicht? Welche Argumente werden gegen Scrum ins Feld geführt?

“Zu viele Meetings” und ”man bekommt zwischen den Meetings kaum etwas geschafft”, hört man wohl am häufigsten.

Insgesamt kann man beachtlich viel falsch machen, Stefan Wolpers hat einen ganzen Guide darüber verfasst (Scrum Anti-Pattern Guide).

Laut Scrum Guide ist Scrum einfach zu verstehen, aber schwer zu meistern. Wenn ich ehrlich bin, habe ich in meiner Karriere mehr schlechte als gute Implementierungen gesehen.

Als ich in den 90ern Lehrer werden wollte, gab es harte Anforderungen. Für Geschichte war eine alte und eine neue Sprache Pflicht. Englisch Voraussetzung. Ich musste mein Latinum nachholen und mein Schulfranzösisch auffrischen. Neben den Hauptfächern musste ich Pädagogik und Philosophie belegen. Dann die Praktika: Als erstes ein Betriebspraktikum. Dann ein Jahr Foreign Language Assisant an einer Highschool in England. Und schließlich noch eins an einer deutschen Schule. Hätte ich mein Ziel weiterverfolgt, hätte ich noch 2 Jahre Referendariat drauflegen müssen. Hätte ich dann im Unterricht immer alles richtig gemacht? Sicher nicht. Aber ich hatte eine gute Vorbereitung.

Scrum Master kann jeder werden. Die Anforderungen sind nicht hoch. Die meisten waren vorher Projektleiter oder Entwickler. Sie werden auf eine 2-tägige Schulung geschickt – fertig.

Es geht mir nicht darum, Kollegen zu verurteilen. Das liegt mir fern.

Die Menschen sind nicht das Problem – sie tun ihr Bestes. Das Problem ist das System.

Verschlimmernd kommt hinzu, dass junge Kollegen selten einen Mentor haben, der sie begleitet. Scrum Master Prüfung bestanden und los geht’s! Dabei wäre es gerade in der Anfangszeit wichtig, sich Feedback zu holen. Ich hatte auch keinen, aber ich habe mir immer regelmäßig Feedback aus dem Team eingeholt.

Wenn die Menschen keine Erfahrung haben, wirkt sich das natürlich aus, vor allem auf die Scrum Events. Meetings sind schlecht vorbereitet, immer nach Schema F, werden sinnentfremdet oder fallen einfach aus.

Das Daily ist häufig einfach ein 15-minütiges Statusmeeting, in dem die Entwickler dem PO berichten, wo man steht. Dabei soll das Daily ein selbstorganisiertes Meeting der Entwickler sein, in dem man die Arbeit der nächsten 24h organisiert, um dem Sprintziel näher zu kommen.

Das Review Meeting verkommt auch häufig zur bloßen Produktdemo. Oft kommen nicht einmal die Entwickler zu Wort. Dabei haben wir hier die Möglichkeit, Feedback einzuholen. Wir können besprechen, was als nächstes das Wichtigste sein wird, und haben die Möglichkeit uns neu zu orientieren.

Die Retrospektive fällt häufig aus („nicht schon wieder…“) oder sie wird nach Schema F durchgeführt (Was war gut, was war schlecht…). Ich halte die Retrospektive mit am wichtigsten von allen Scrum Events. In allen Events geht es um inspect & adept, vor allem aber in der Retrospektive.

Retrospektiven kann man spannend gestalten. Man findet so viele Anregungen im Netz, angefangen beim Retromat. Auch Spezialliteratur, die sich nur mit diesem Event beschäftig, ist ausreichend vorhanden. Eine gute Idee ist, als Scrum Master hier und da Schwerpunkte zu setzen und Methoden so auszuwählen, dass auf aktuelle Probleme eingegangen werden kann. Wichtig ist, dass am Ende tatsächlich Handlungsanweisungen herauskommen, die SMART (specific, measurable, achievable, realistic, time-bound) sind. Eine gute Idee ist, diese im Backlog anzulegen, um ihre Umsetzung dort zu tracken. Kein Muss, aber sicher eine gute Praxis.

Sprint Plannings verkümmern oft in einem bloßen Anlegen von Unteraufgaben im entsprechenden Taskmanagement Werkzeug, z.B. Jira. Dabei geht es darum, dass das Team nicht nur das WAS, sondern auch das WIE bespricht. Wie setzen wir etwas um? Was gilt es in Bezug auf die Definition of Done zu beachten? Idealerweise sind die Product Backlog Items im Refinement so vorbereitet worden, dass man für solchen Dinge auch wirklich Zeit hat. Bei einer Sprintdauer von 4 Wochen sind für das Planning 8h erlaubt. 8h können sehr lang sein, wenn sie falsch eingesetzt werden. Sie können aber auch lustvoll, voller Kreativität und Energie sein, wenn das Team als Team die Planung des Sprint Backlogs angeht.

Ich muss gestehen, dass ich vieles anfangs selbst nur oberflächlich verstanden habe. Erst in dem Moment, als ich die Rolle des Scrum Masters übernahm und selbst in der Verantwortung stand, habe ich angefangen, mich intensiver mit dem Thema auseinanderzusetzen. Und erst dann ist mir hier und da ein Licht aufgegangen.

Führt man ein Framework ein, sollte es einen bestimmten Zweck erfüllen.

Ich führe in der Software-Entwicklung nicht REACT ein, weil es hip ist, sondern weil es mir viel Arbeit abnimmt, erprobt und qualitativ hochwertig ist. Unter anderem.

Warum ist es eine gute Idee, Scrum einzuführen?

In erster Linie geht es darum, dass das Team zusammen erfolgreich ein Produkt entwickelt. Meistens haben die Mitarbeiter so noch nie zusammengearbeitet. Weder über Gewerkgrenzen hinweg noch innerhalb des Teams. Scrum Werte wie beispielsweise Offenheit sind ihnen fremd und müssen erst gelernt werden. Den Vorteil, den ich in Scrum sehe, sind die fest verankerten Feedbackzyklen. Mit einem unerfahrenen Team würde ich immer versuchen, mich auf eine Sprintlänge von einer Woche zu einigen, um in kurzen Abständen Arbeitsweise prüfen und anpassen zu können.

Des Weiteren ist die Rolle des Scrum Masters fest vorgeschrieben. Er begleitet den Change- und Lernprozess und ist in summa für ihn verantwortlich. Er ist da, um Product Owner und Team zu unterstützen, zu coachen, zu unterweisen.

Wie oft sieht man, dass diese Rolle einfach unbesetzt bleibt. „Nein, den Scrum Master bezahlen wir nicht. Da sehen wir keinen Nutzen.“ „Nein? Ach so, gut ok…“

Erfolg hat viele Gründe. Aber beginnen sollte man mit dem Coach. Hätte Liverpool den Erfolg der letzten Jahre ohne Jürgen Klopp gehabt? Wären wir ohne Nagelsmann nicht wieder in der Vorrunde ausgeschieden? Eine Person, die den Change Prozess begleitet, vorlebt, erklärt, Dinge im Mindset der Menschen ändert, ist immanent wichtig.

Photos by https://unsplash.com/