Die Top 3 Fehler bei der Einführung von Scrum und agilen Arbeitsweisen

„Scrum funktioniert bestimmt … nur halt nicht bei uns.“ Während die einen schon von Scrum 3.0 reden, ist das für die anderen noch immer ein böser Trend, der hoffentlich bald wieder aufhört. Auch in Trainings erleben wir Teilnehmer, die nicht aus echtem Interesse am Thema dabei sind, sondern weil sie eben „etwas über Agilität lernen müssen“.Sobald die Teilnehmer aber in der Lage sind, ihre eigenen Projekte in der Stacey Matrix einzuordnen, erscheint das erste Leuchten auf den Gesichtern, weil sie verstehen, dass Scrum ihnen besonders im komplexen Umfeld hilft. Das Eis ist gebrochen, und es entsteht Interesse, doch noch etwas über Scrum zu lernen. Diese Frage taucht dann auch immer wieder auf: Was kann man bei der Einführung von Scrum falsch machen?

Fehler #1: Das Management steht nicht (wirklich) hinter der Veränderung

Drei Fehler begegnen uns besonders oft, selbst bei Scrum-Trainings. Wenn ich z.B. Teilnehmer habe, die „von den Führungskräften zum Training geschickt“ worden sind, hake ich nach, ob ebendiese Führungskräfte selbst ein solches Training besucht oder zumindest ein Grundverständnis für das Thema haben. Das ist die erste Stolperfalle bei der Einführung von Scrum. Denn dann steht das Management ganz nach dem Motto „Veränderung – ja, gerne, so lange ich mich nicht ändern muss“ nicht wirklich hinter der Veränderung, die Scrum bzw. agiles Arbeiten mit sich bringen wird: neue Rollen, entscheidungsfähige, autonome Teams und eine neue Art der Führung.Dann werden Handouts oder Broschüren mit der Überschrift "agile@Unternehmen XY" verfasst, die schildern, wie die agile Welt im Unternehmen aussehen soll. Aber die Planung hat mit der Unternehmensrealität oft wenig zu tun, was den Mitarbeitern natürlich nicht verborgen bleibt.Ich komme zwar als externer Agile Coach bzw. ScrumMaster in die Organisation, um die Veränderung anzustoßen. Das geht aber schneller (und Teams liefern kontinuierlicher), wenn Führungskräfte Agilität verstehen und sich an der Umsetzung beteiligen, anstatt an alten Top-Down-Strukturen festzuhalten. Ein einzelnes Team kann trotzdem mit Scrum erfolgreich sein. Um die ganze Organisation zu transformieren, braucht es jedoch auch die Unterstützung der Führungsebenen.

Fehler #2: Die Mitarbeiterinnen und Mitarbeiter haben keinen Willen zur Veränderung und zum Lernen

Das Festhalten an alten Strukturen und Denkmustern ist der zweite Fehler, der uns in Projekten und Abteilungen, die agil arbeiten sollen, immer wieder begegnet: Wer nicht bereit ist, an sich zu arbeiten, Arbeitsweisen zu hinterfragen, hierarchisch denkt oder dessen Lieblingssatz „das haben wir schon immer so gemacht“ ist, der ist nicht bereit für Scrum und Co.Ein Reibungspunkt ist die Meetingstruktur: Bei Scrum scheinen wir zunächst viel mehr Zeit als vorher in Meetings zu verbringen. Wenn diese Meetings aber effektiv genutzt werden, braucht es kaum noch zusätzliche Abstimmungen per Mail oder Telefon. Denn jeder weiß, woran die anderen arbeiten und wir haben feste Zeiten für einen Austausch. In der reichlich verbleibenden Zeit kann ungestört gearbeitet werden. Wenn zusätzlich zu den Scrum Meetings parallel die bisherigen Meetings weiterlaufen, müssen wir sie hinterfragen (Brauchen wir sie noch? Wird in den Meetings das Richtige besprochen? Sind die richtigen Personen dabei?) und wenn möglich reduzieren.

Fehler #3: Das Skalierungs-Framework passt nicht zu den Projekten oder zur Organisation

Der dritte Fehler betrifft die Einführung von agilen Frameworks für mehrere Projekte gleichzeitig. Wenn man ein Model wie Scrum of Scrums, SAFe, LeSS o.ä. einführen will, muss man sich zunächst anzuschauen, was zur Organisation bzw. Abteilung(en) und deren Produkten passt. Grundsätzlich scheint es natürlich einfacher, ein solches Framework als Zielzustand zu betrachten und Abteilungen daraufhin umzustellen. Doch jedes Framework hat Schwerpunkte und folglich auch Schwachstellen. Hilfreich ist es, wenn die Wahl verbunden ist mit der Bereitschaft, auf dem Weg zum Zielzustand Korrekturen (inspect & adapt) vorzunehmen. „Blaupausen“ oder „Best Practices“, die in der klassischen Beratung gerne angewendet werden, können im Konflikt mit dem stehen, was wirklich zur Organisation passt und was diese auf dem Weg der Transformation lernt.Deshalb empfehle ich euch, lieber mit einzelnen Projekten klein anzufangen und ein Managementframework zu testen, um dann von den erfolgreichen Scrum-Teams für die Skalierung zu lernen und diese Learnings in die Organisation zu tragen. Das empfahlen schon Takeuchi und Nonaka 1986 in ihrem Artikel „The new new product development game“.Foto: Unsplash License, Kelly Sikkema