Herausforderungen bei der Einführung von Scrum

Zu der Einführung und Nutzung von agilen Rahmenwerken wie Scrum existiert eine Vielzahl von Erfolgsmeldungen. Viele Unternehmen berichten darüber, dass nun vieles besser funktioniert, die Qualität gestiegen ist und die Kundenzufriedenheit zugenommen hat. Es entsteht der Eindruck, als ob agile Rahmenwerke die Lösung für eine Vielzahl von bedeutenden Herausforderungen im Unternehmen darstellen. Ein tiefergehender Blick in die Unternehmensstrukturen- und abläufe zeigt jedoch häufig, das Jeff Sutherland und Ken Schwaber Recht haben mit der Aussage, dass Scrum einfach zu verstehen, aber schwierig zu meistern ist“ (Schwaber und Sutherland, 2017, S. 3).

Scrum zählt seit vielen Jahren zu dem beliebtesten und am häufigsten verwendetsten Rahmenwerk (Komus und Kuberg, 2017, S. 10) „innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können (Schwaber und Sutherland, 2017, S.3). Viele Unternehmen möchten die Vorteile, die Scrum verspricht, nutzen. Dazu zählen u.a. die starke Kundenorientierung, Termintreue, Qualitätssteigerung und eine Erhöhung der Effizienz. Die Einführung und erfolgreiche Nutzung des Rahmenwerks verspricht zudem wichtige Wettbewerbsvorteile gegenüber Mitbewerbern. Demnach haben bereits viele Unternehmen den Schritt gewagt und auf unterschiedlichste Weise Scrum eingeführt.

So verlockend all die zuvor genannten Vorteile sind, die Erzielung birgt eine Reihe von Herausforderungen, die es zu bewältigen gilt. Nachfolgend möchte ich auf 3 Herausforderungen bei der Einführung von Scrum eingehen und verdeutlichen, welche enormen Anstrengungen notwendig sind, um die Potentiale von Scrum voll ausschöpfen zu können.

Die 3 Herausforderungen bei der Einführung von Scrum

1 - Scrum ist ein Mittel, nicht das Ziel

Die Einführung von Scrum wird von einigen Unternehmen als Ziel verstanden und definiert. Diesem Oberziel werden Unterziele und konkrete Maßnahmen zugeordnet. Häufig wird ein eigenes Projekt oder eine Organisationseinheit aufgebaut, die sich der Einführung vollständig zuwendet. Es wird überlegt, wie skaliert werden kann und ganze Unternehmensbereiche werden geschult und zertifiziert. Nach einer gewissen Zeit wird anhand von Kennzahlen der Zielerreichungsgrad geprüft und festgehalten, ob die zuvor festgelegten Ziele erreicht wurden.

Eins dieser Ziele, die geprüft werden, könnte lauten „10 Softwareentwicklungsprojekte werden mittels Scrum bis Ende des nächsten Jahres realisiert“. Ein Weiteres „25% der IT-Mitarbeiter sind zertifiziert“. Diese Ziele sind keineswegs sinnlos oder falsch, jedoch verfehlen sie das Wesentliche. Was bringt es dem Unternehmen, dass Projekte mittels Scrum und nicht per Wasserfall durchgeführt werden und welchen Mehrwert liefern zertifizierte Product Owner und Scrum Master? Ist das eigentliche Ziel nicht viel mehr, den Umgang mit komplexen Aufgaben zu verbessern, um die Unternehmensziele bestmöglich zu erreichen?

Hierfür kann Scrum ein Mittel der Wahl sein. Bevor Unternehmensbereiche und Projekte initiiert werden, sollte geprüft werden, wofür das alles konkret benötigt wird. Zentral sollte die Fragestellung sein: „Wie können mir agile Rahmenwerke dabei helfen meine Unternehmensziele zu erreichen?“ Hierbei plädiere ich für eine kritische Auseinandersetzung mit agilen Rahmenwerken und klassischen Vorgehensmodellen. Wenn die Entscheidung dann tatsächlich auf Scrum fällt, dann kann es als Mittel zur Erreichung von Zielen zum Einsatz kommen und all die Bemühungen, die notwendig sind, dienen nicht dem reinen Selbstzweck.

2 - Customizing der Rollen, Meetings und Artefakte

Insbesondere große Unternehmen haben über die Jahre eine Organisation aufgebaut, die eine Vielzahl von Hierarchiestufen und Rollen umfasst. Nun kommt Scrum daher und möchte 3 weitere Rollen implementieren: den Product Owner, den Scrum Master und das Entwicklungsteam. Es ist es ja nicht so, als hätten die Aufgaben und Verantwortlichkeiten dieser 3 Rollen vorher nicht existiert und als gäbe es nicht schon konkrete Mitarbeiter, die diese Rollen einnehmen könnten. Aber wie passen diese 3 Rollen nun in die Unternehmensstrukturen- und abläufe und was ändert sich dadurch alles?

Dieser Frage begegnen einige Unternehmen mit einem Umstrukturierungsprojekt, Andere integrieren die Rollen in die bestehende Organisation. Zu Letzterem sind der Phantasie keine Grenzen gesetzt: So wird reduziert, erweitert und interpretiert:

• Reduzierung: Scrum Teams werden ohne Scrum Master besetzt, Retrospektiven werden gekürzt und anschließend gar nicht mehr durchgeführt und die User Stories umfassen lediglich Überschriften zur Arbeitsteilung ohne gemeinschaftliche Einwertung, z. B. Mittels Planning Poker.

• Erweiterung: Ein Projektleiter steuert mehrere Teams und führt neue Status- und Reportingstrukturen ein. Das bestehende Test- und Qualitätsmanagement wird nach wie vor zentral aufgestellt und stellt Vorgaben an die agilen Teams, die in der Definition of Done integriert werden.

• Interpretation: Die bestehenden Entwickler heißen im agilen Team nun „Full-Stack-Entwickler“ und es wird einfach davon ausgegangen, dass Sie nun alle notwendigen Disziplinen beherrschen. Der Scrum Master übernimmt organisatorische Aufgaben, wird von einem PMO-Mitarbeiter besetzt und kann mehrere Teams gleichzeitig unterstützen.

Fälschlicherweise besteht insbesondere bei Führungskräften die Annahme, dass Scrum ein generisches Rahmenwerk ist, das frei interpretiert und gecustomized werden kann bzw. sogar muss. Schließlich kann die Theorie (Scrum Guide) nicht in die Praxis adaptiert werden. Tatsächlich steht im Scrum Guide „Das Scrum-Rahmenwerk besteht aus Scrum-Teams und den zu ihnen gehörenden Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Rahmenwerks dient einem bestimmten Zweck und ist unentbehrlich für den Einsatz von Scrum und dessen Erfolg“ (Schwaber und Sutherland, 2017, S.3). Schauen wir uns die 14 Autoren des agilen Manifests inkl. der beiden Initiatoren von Scrum genauer an, stellen wir fest, dass keiner von Ihnen Theoretiker ist. Vielmehr sind die CIO’s, CTO’s, Entwickler und Tester. Allesamt tätig in oder für Unternehmen.

Die Einführung von Scrum ist keine einfache Aufgabe. Ist es dann nicht deutlich leichter, die Vorgaben zu implementieren, über die sich fähige Menschen viele Jahre Gedanken gemacht und ständig verprobt und weiterentwickelt haben? Wenn dieser Schritt getan ist, ist es natürlich keineswegs verboten, eher sogar ausdrücklich gewünscht, diese Vorgehensweisen zu überprüfen und anzupassen (Inspect & Adapt). Sollten die Rollen, Meetings und Artefakte des Scrum Rahmenwerks nicht implementierbar sein, wäre auch die Frage erlaubt, warum dies so ist? Evtl. wäre das Reduzieren, Erweitern und Interpretieren der bestehenden Ist-Strukturen und Prozesse im Unternehmen ja ratsamer?

3 - „Big Bang“ Einführung

Die Entscheidung, Scrum einzusetzen, wird häufig vom Management getroffen. Es gibt natürlich viele Wege, um dieses Vorhaben anzugehen. Ein erster Schritt sollte sein, sich über Motive der Einführung und den Beitrag zur Zielerreichung klar zu werden (siehe Punkt 1). Häufig wird dieser Punkt übersprungen und es wird ein Team, Projekt, Programm oder eine Abteilung als Pilot ausgewählt.

Nun kann es im nächsten Monat ja losgehen. Schließlich ist Scrum leicht verständlich, die 18 Seiten Anleitung (Scrum Guide) sind schnell gelesen und eine 2 tägige Schulung fix gebucht. Nach einigen Sprints folgen die ersten Schwierigkeiten: Die Entwicklungs- und Testumgebungen sich nicht bereit für iteratives- und inkrementelles Arbeiten; die Fachbereiche (vertreten durch die Product-Owner-Rolle) haben zu wenig Zeit, um Input zu liefern; Abhängigkeiten zu anderen Unternehmensbereichen, die nicht agil arbeiten, führen zu Konflikten; usw.

Die Einführung sollte gut geplant, abgestimmt und kommuniziert werden. Schließlich hängt der Erfolg von IT-Projekten stark mit der ersten Phase des Projekts zusammen. So auch in agilen IT-Projekten. Die zuvor genannten Schwierigkeiten sind im Vorfeld lösbar. Eine Ist-Analyse der bestehenden Strukturen und Vorgehensweisen im Pilotumfeld sowie den Schnittstellen zu anderen betroffenen Bereichen liefert eine gute Ausgangsbasis.

Anschließend sollte herausgearbeitet werden, was konkret getan werden muss, um im Soll-Szenario arbeiten zu können. Diese Maßnahmenliste kann z. B. in ein Backlog fließen und in Form eines Scrum-Teams umgesetzt werden.

Wichtiger ist aber vielmehr, dass diesem Vorhaben ausreichend Zeit eingeräumt wird, eine transparente Kommunikation über die Inhalte und Ziele des Vorhabens stattfindet und die Begleitung durch erfahrene agile Coaches erfolgt.

Fazit

Scrum ist ein einfaches und verständliches Rahmenwerk, deren Einführung und Verwendung in der Praxis häufig Herausforderungen mit sich bringt. Dazu zählt eine falsche Zielsetzung, die Scrum in den Mittelpunkt stellt und nicht die eigentlichen Ziele des Unternehmens. Ein Customizing des Rahmenwerks in vielen erdenklichen Möglichkeiten und nicht die Anpassung der bestehenden Strukturen und Vorgehensweisen sowie eine frühzeitige und undurchdachte Einführung.
Diesen Herausforderungen kann begegnet werden mit einer kritischen Auseinandersetzung mit agilen und klassischen Rahmenwerken und Nutzung als Mittel zur Erreichung von Unternehmenszielen. Die Anwendung von bewährten und verprobten Rollen, Meetings und Artefakten und einer Überprüfung und Anpassung bestehender Strukturen und Abläufe sowie einer durchdachten Einführungsstrategie, deren Umsetzung von agilen Experten begleitet wird.

Quellen:

• Schwaber und Sutherland, Der Scrum Guide; abgerufen am 07.02.2019

• Komus und Kuberg, Status Quo Agile; abgerufen am: 07.02.2019