Von der schwierigen Scrum-Einführung zum ScrumAnd

von Andrea Herrmann
 

Zu den vielen Scrum-Erfolgsgeschichten gesellen sich auch Berichte über Einführungsschwierigkeiten sowie über das Bedürfnis, Scrum anzupassen oder zu ergänzen. Das ist im Grunde nicht sehr verwunderlich, da Scrum einen sehr streng durchgetakteten Arbeitsrhythmus vorgibt, der vielleicht nicht überall passt. Außerdem macht es viel weniger Vorgaben als andere Vorgehensmodelle, eben nur die allernötigsten. In diesem Artikel geht es um praktische Einführungsschwierigkeiten, um die beliebtesten und unbeliebtesten Scrum-Praktiken und häufig praktizierte Anpassungen. Letztlich ist Scrum vielleicht vor allem ein idealer Ausgangspunkt für die Entwicklung eines firmen- oder teamspezifischen Vorgehensmodells, weil Scrum erstens mit einem Mindestsatz an Managementtechniken startet und zweitens die regelmäßige Überprüfung und Verbesserung der Arbeitsweise beinhaltet.

Obwohl die dokumentierte Geschichte von Scrum mehr Erfolgs- als Misserfolgsmeldungen umfasst, gibt es auch anderslautende Berichte über Herausforderungen bei der Einführung und von einzelnen Mitarbeitern, die sich ausklinken, Firmen, die Scrum wieder aufgeben. Vermutlich gibt es in den Publikationen einen „publication bias“: Erfolgsgeschichten werden eher veröffentlicht als Misserfolge.

Inzwischen gibt es aber nicht nur unter der Hand im vertraulichen Zweiergespräch Berichte über wenig erfolgreiche Scrum-Einführungen, sondern auch in der Fachliteratur kommen sie immer wieder vor.

Grundsätzlich treten beim Übergang zu Scrum dieselben Schwierigkeiten und Schmerzen auf, wie sie generell bei der Einführung neuer Arbeitsweisen häufig auftreten: Nicht alle Betroffenen stehen hinter der Änderung und halten sich an die Regeln, es fehlt die Erfahrung mit den Methoden oder die neue Arbeitsweise passt nicht zur Firmenkultur. Darum gibt es ja die Disziplin des Change-Managements, und die Einführung von Scrum muss auf jeden Fall durch ein Change-Managementkonzept begleitet werden. Dazu gehört die Unterstützung der Umstellung durch das Management und das Ins-Boot-Holen der Mitarbeiter, die Definition von Vorgehensweisen und die Bereitstellung von Werkzeugen, die Schulung der Betroffenen und die Unterstützung durch Change-Champions und Experten (beispielsweise einen zertifizierten Scrum Master).

Die am häufigsten genannten Schwierigkeiten bei der Scrum-Einführung – abgesehen von den oben genannten Change-Managementproblemen – lauten (z. B. bei [Mar08], [Haj11] [Kra14]):

• Kunde: Scrum betrifft nicht nur das Scrum-Team und das Management innerhalb der Firma, sondern auch den Kunden. Passt Scrum nicht zu dessen Vorgaben, dann muss irgendein Kompromiss gefunden werden, beispielsweise ein ScrumAnd: Man macht Scrum und erstellt noch zusätzliche Dokumente oder führt zusätzliche Aktivitäten aus, um diese Vorgaben zu erfüllen.

• Aufwandsschätzung: Die Aufwandsschätzung wird zwar genauer, wenn man kleine statt große Arbeitspakete schätzt, und doch verschätzen sich auch Scrum-Teams. Somit muss am Ende der Timebox Arbeit in den nächsten Sprint verschoben werden, das Sprint-Ziel wurde nicht erreicht. Wenn man Scrum richtig anwendet, führt allerdings das Lernen zu immer besseren Prognosen.

• Product Owner: Der Product Owner formuliert unklare Anforderungen oder ist nicht kompetent, um alle Arten von Anforderungen zu liefern.

• Besprechungsdisziplin: Die Scrum-Events folgen einer klar definierten Tagesordnung und behandeln nur die vorab definierten Fragen. Trotzdem kommt es auch in Scrum-Meetings vor, dass die Diskussion nicht im Zeitrahmen bleibt und auch nicht beim Thema. Dieses Problem bestand vermutlich schon vor der Scrum-Einführung und wird durch Scrum erst richtig sichtbar.

• Backlog-Verwaltung: Der Aufwand für die Verwaltung des Backlogs ist hoch. Darum wird das Backlog nicht so ordentlich gepflegt, wie es sein sollte. Damit fehlt dem Team jedoch eine verlässliche Informationsgrundlage für wichtige Entscheidungen.

• Rollen, Selbstverständnis und Karrierewege: Die drei Scrum-Rollen Development Team (kurz Team), Scrum Product Owner und Scrum Master wirbeln nicht nur die Rollenbezeichnungen innerhalb eines Projektteams durcheinander, sondern auch die Bezeichnungen der Positionen innerhalb der Firma. Außerdem erweitern sie das Aufgabenspektrum von Mitarbeitern sowie die geforderten Qualifikationen. Es verändert oder beseitigt eventuell sogar bisher existierende Karrierewege, zum Beispiel vom Junior zum Senior. Wie macht man eigentlich Karriere innerhalb von Scrum?

• Spezialisten: Obwohl Scrum auf generalistisch qualifizierte Mitarbeiter hofft, die flexibel alle anstehenden Aufgaben übernehmen können, führt die technologische Komplexität in der Praxis doch oft dazu, dass Entwickler zu Experten werden, die sich mit einer bestimmten Technologie besonders auskennen und eventuell sogar nur mit dieser Technologie arbeiten. Diese ziehen ihrer eigenen Wahrnehmung nach wenig Nutzen aus dem Daily Stand-up und bleiben darum fern.

• Mikromanagement: Vorgesetzte nutzen die durch Scrum erzeugte Transparenz über den Arbeitsfortschritt und die kleinteilige Planung dazu, ihre Mitarbeiter im Detail zu überwachen und in die Selbstorganisation des Teams einzugreifen. Dann wird aus dem Pull-Prinzip ganz schnell wieder Push, aus dem „sustainable pace“ der alte Stress. Vor lauter Prozessen und Werkzeugen kommen dann das Zwischenmenschliche und die Kommunikation doch zu kurz. Insbesondere werden Fehler, die jemand macht, schonungslos offenbar.

• Kulturelle Änderung: Es werden zwar die Praktiken ausgeführt, aber die Denkweise in den Köpfen ist noch nicht agil. Das genügt nicht. Der Wandel muss wegführen vom streng hierarchisch organisierten Projekt, bei dem der Projektleiter für alles verantwortlich ist. Das Scrum-Team organisiert sich selbst mit allen Vor- und Nachteilen: Entscheidungen werden gemeinsam getroffen und sind verbindlich, wer eine Aufgabe übernimmt, ist dafür verantwortlich.

Alle diese Schwierigkeiten verhindern nicht unbedingt die Scrum-Einführung, führen jedoch zu Frust und müssen gezielt abgefangen werden.

Über Extreme Programming (XP) schrieb Kent Beck [Beck00], man müsse alle seine Praktiken anwenden, weil die Nachteile der einen durch andere ausgeglichen werde. Scrum sieht nach dem Leitfaden von Schwaber und Sutherland [Scrum] allerdings ausdrücklich vor, dass in der Retrospektive der Arbeitsprozess angepasst wird. Dabei kann das Team entscheiden, Praktiken wegzulassen, durch andere Praktiken zu ersetzen oder durch weitere zu ergänzen. So entstanden verschiedenste Scrum-Varianten:

• ScrumBut: Wir machen Scrum, aber wir lassen diese und jene Praktik weg.
• ScrumAnd: Wir machen Scrum und ergänzen es um eine oder mehrere zusätzliche Praktiken.
• ScrumBan: Eine Mischung aus Scrum und Kanban.
• Water-Scrum-Fall: Hier wird nur die Implementierung mit Scrum durchgeführt, aufbauend auf einem Big Upfront Design (BUD), Machbarkeitsstudie und Festpreis-Budgetierung, und dann abgeschlossen durch eine Qualitätssicherung des Gesamtsystems und einer Big Bang-Einführung.
• Large Scale Scrum (LeSS): Ein Vorgehen, bei dem mehrere Scrum-Teams dasselbe Product Backlog verwenden [LeSS].
• Scaled Agile Framework (SAFe): Hier arbeiten die Scrum-Teams eingebettet in ein Umfeld von Programm- und Portfolio-Management [SAFe].

Diese Liste ist vermutlich nicht vollständig und wird sich zukünftig auf jeden Fall noch verlängern. Allein dies ist ein Indiz dafür, dass Scrum nicht überall in derselben Reinform passt.

Abbildung 1 zeigt die Liste der Scrum-Praktiken und der XP-Praktiken  und dazwischen dargestellt solche, die in ScrumAnds gerne zusätzlich noch eingesetzt werden.