Wie gelingt die Einführung von Scrum?

Transition mit Team: Wie gelingt die Einführung von Scrum? Das ist eine Fragestellung, mit der ich mich als Business Coach und Scrum Master mittlerweile häufiger beschäftige, weil „Scrum-Neukunden“ oft darüber stolpern.

Von Scrum haben mittlerweile viele Unternehmen etwas gehört. Wer offen ist für etwas Neues und interessiert daran, dass Mitarbeiter auf innovative und eigenverantwortliche Weise Projekte zum Erfolg führen, spielt mit dem Gedanken, Scrum bei sich einzuführen. Dazu gibt es Lektüre (siehe auch den Beitrag Scrum: Schneller ans Ziel kommen in unserem Blog) und es gibt Coaches und Scrum Master wie mich, die dabei helfen. Soweit die Theorie! In der Praxis aber sind die Unternehmen – vor allem: Ihre Mitarbeiter und Führungskräfte – mit vielen Fragen konfrontiert. Wie wird ein Team eigentlich „scrum“, was bedeutet das für die althergebrachte Ordnung?

Anfang mit Reibungsverlusten

Dass es anders wird, agil zusammen zu arbeiten als im klassischen Projektmanagement, das ist vielen Klienten klar. Ich erlebe immer wieder, dass viele die Höhe der Hürde unterschätzen, die es beim Übergang von klassisch zu agil zu nehmen gilt. Es ist vor allem eine innere Hürde: Sie macht sich zum ersten Mal richtig bemerkbar, wenn die anfängliche Motivation (die ja oft da ist, wenn etwas Spannendes, Neues geschieht) langsam nachlässt. Schauen wir uns mal folgendes Szenario an:

Eine Software-Entwicklungsfirma, die Zulieferer für einen Automotivekonzern ist, stemmt jahrein-, jahraus Hunderte Projekte. In der Entwicklungsabteilung haben die drei vorhandenen Projektleiter ihre Ausbildung zum Scrum Master absolviert. Sie beschließen nun, Scrum einzuführen. Sie können das in einem einzigen, furiosen Zug tun und ihre Teams damit konfrontieren, dass ab dem nächsten Projekt alles nach Scrum-Prinzipien läuft. Das geschieht in der Praxis häufig.

Das war auch der Grund, weshalb ich an den Schauplatz der Entwicklungsabteilung gerufen wurde: So rasch und reibungslos wie von der Geschäftsleitung erwartet, läuft es nicht. Man hat es zunächst mit der Methode „beim nächsten Projekt wird alles agil“ probiert und stieß auf eine Reihe Probleme: Rollenkonflikte, ungeklärte Fragen, verwirrte Stakeholder und die Suche nach der tatsächlichen, „wahren“ Zielgruppe des Projekts. Für mich als Business Coach und Scrum Master ist es als Erstes interessant zu erfahren, weshalb sich die Projektleiter für Scrum entschieden haben. Die Entwicklung in der Automotivebranche muss extrem innovativ sein, ihrer Zeit ständig voraus und sie braucht gute Vordenker und Experten, die bereit sind, ausgetretene Pfade erst gar nicht zu betreten. Unsicheres Umfeld, komplexe und sich dauernd ändernde Technologien: Wie in der IT üblich (wo Scrum ja herkommt), eignet sich Scrum daher im Prinzip gut für Entwickler. Im Gegenzug lassen sich Projekte am besten klassisch abwickeln, wenn langfristig geplant werden kann, äußere und technologische Rahmenbedingungen sich nicht ständig ändern. Insofern war dieser Punkt geklärt: Scrum war (und ist) eine geeignete, agile Methode für ein agiles Umfeld. Das heißt allerdings nicht, dass auch die Teams so agil wie erhofft reagieren.

Scrum verzichtet auf Hierarchien

Im Gegenteil: Während viele der Mitarbeiter positiv auf die Neuerung ansprachen, zeigten sich andere praktisch resistent. Man kann es Angestellten eigentlich nicht verübeln, wenn es von oben heißt: „Egal, wie Ihr das in den letzten zehn Jahren gemacht habt, jetzt brechen andere Zeiten an, seht es doch als Chance!“ Für so Manchen bedeutet „Chance“ nämlich ein Heraustreten aus dem bequemen Kokon, das Verlassen bekannter Pfade und somit natürlich Unsicherheit. Auch beim Automotive-Zulieferer bekannten sich mir als Coach gegenüber einige Mitarbeiter unter vier Augen, dieser neuen Art der Projektarbeit sehr skeptisch gegenüber zu stehen: Sie sahen sich als „einfaches Entwicklungsteam-Mitglied“ förmlich degradiert. Die Rolle des Product Owners (PO) erschien viel prestigeträchtiger zu sein – ein häufiges Missverständnis, wenn Scrum neu eingeführt wird. Scrum verzichtet nämlich auf Hierarchien, was von so manchem ehemaligen Projektleiter zunächst als einschneidend empfunden wird. Es kann nur leider pro Projekt einen PO geben. Die Erkenntnis, dass das Entwicklungsteam gleichwertig zusammenarbeitet und eigenverantwortlich handeln darf, ist für Mitarbeiter in einem klassischen, hierarchisch aufgebauten Unternehmen mitunter erst einmal schwer zu begreifen.

Agile Teams brauchen agile Unternehmensstrukturen

Auch wenn die Zulieferer-Firma in ihrer Gesamtheit recht modern und offen geführt wurde, so traf das selbstorganisierte Team aus der Entwicklung immer wieder auf Strukturen und Prozesse im Unternehmen, die traditionell liefen, etwa das Controlling und die Budgetierung. Dann stand schnell die Frage im Raum: Umdenken, einfach weitermachen oder von anderen erwarten, dass sie sich in die Regeln einarbeiten?Teams können nur so agil sein wie ihre Vorgesetzten. Werden neue Projektmethoden eingeführt wie Scrum, oder ist ein anderer kultureller Übergang zu meistern, braucht es ein evolutionäres Weltbild im Unternehmen. Das bedeutet, der CEO bzw. der Vorstand und möglichst weite Teile der Führungsriege müssen davon überzeugt sein, dass sich Mitarbeiter ändern und weiterentwickeln können. Die Haltung sollte sein: Wir fördern Entwicklung, keiner bleibt dabei auf der Strecke. Wie können wir Menschen motivieren, neue Wege zu gehen? Auch diejenigen, die vielleicht schon kurz vor der Rente stehen? Gerade in Zeiten des Demografiewandels in Unternehmen ist entscheidend, ob man davon ausgeht, dass auch eine alternde Belegschaft noch beweglich ist – oder ob man der Ansicht ist „die wollen es doch so machen wie immer.“ Oft blockiert auch eine Haltung, die davon ausgeht, man müsse Mitarbeiter kontrollieren, um Ergebnisse zu erzielen. Beides war immerhin bei meinem Einsatz beim Automotive-Zulieferer nicht der Fall.

Ein großes Problem war wie bei vielen „Scrum-Anfängern“ der holprige Übergang. Idealerweise begleitet schließlich ein erfahrener Scrum Master das Team bei dieser Transition. Er fungiert wie ein Mentor und ein guter Coach zugleich. Dabei ist er Ansprechpartner für das ganze Entwicklungsteam wie auch für jeden Einzelnen davon. Auf der Zeitschiene eines Projekts betrachtet, arbeitet der Scrum Master zu Beginn des Projekts und zu seinem Ende hin eher wie ein Teamcoach (bezogen auf die einzelnen Sprints). Die Projektmitte kennzeichnen – da gibt es meist keinen Unterschied, ob ein Projekt agil oder klassisch gemanaged wird – gerne mal zwischenmenschliche Konflikte, Ängste und Sorgen. Dann ist der Scrum Master eher wie ein persönlicher Coach und der Fokus liegt verstärkt auf dem einzelnen Mitglied. Nun waren die Scrum Master beim Automotive-Zulieferer noch nicht sehr erfahren in der Scrum-Praxis. Als Scrum Master und Business Coach kam mir daher die eben beschriebene Rolle des Mentors zu. Es ging dabei vor allem darum, die oben genannten Unsicherheiten im Team abzubauen und die Prinzipien von Scrum in den Köpfen zu verankern. Sprich: Wir stärkten die neuen Rollen. Das galt auch für den Product Owner. Dieser soll sich bis zum Zielbild des „Mini CEOs“ entwickeln. Letztlich soll bei Scrum ja das Team wirklich als hoch entwickeltes High-Performance-Team zusammenwirken; die Definition of Done soll wirklich ihren Zweck erfüllen. Selbstverständlich bestand meine Arbeit auch darin, zu helfen, ganz grundsätzlich ein sauberes Projekt mit Scrum aufzusetzen:

Start mit der Benennung des Scrum Teams
Einsetzen eines von allen anerkannten Product Owners
Aufsetzen eines Entwicklungsteams mit 8 Mitgliedern (bei Scrum sollen es 3 bis 9 sein)
Einsetzen des Scrum Masters
Erstellen des Product Backlogs
Übersicht über die Werkzeuge und Artefakte für das Projekt

Für den Change in dieser Abteilung, wo IT-Experten, Ingenieure und Entwickler zusammenarbeiteten, war enorm wichtig, alles Schritt für Schritt zu tun und damit in Zeiten des Wandels für Ordnung und Stabilität zu sorgen. Gleichzeitig ging es immer wieder darum, das Geschehen zu beobachten, achtsam zu sein und zuzuhören. In diesem Fall war dies alles relativ problemlos zu bewerkstelligen, da Scrum erst einmal in einer einzelnen Abteilung eingeführt wurde für ein anstehendes Projekt.

Scrum: Ein spannendes Feld mit vielen neuen Fragen

Die besten Praxiserfahrungen mit Scrum sind, die Methode zunächst nur mit einem Team und einem Projekt einzuführen. Die auftretenden Probleme werden dabei hoffentlich von einem sehr überzeugten Chef (und hoffentlich einer Geschäftsleitung, die eine gewisse Reife und Weltsicht entwickelt hat) sowie allen Beteiligten, die im Sinne von Scrum gut ihre Rollen übernehmen, gelöst. Die meiste Verantwortung liegt dabei auf dem Scrum Master, der den Spagat zwischen Mentor/Trainer, Teamcoach und Einzelcoach gut gebacken kriegen muss.

Das Thema „Übergang zu Scrum“ ist ein weites Feld, aber auch ein extrem spannendes, wie ich finde. Nicht wenige Unternehmen beschäftigen sich aktuell damit. Und stehen dabei erst am Anfang, denn noch hat Scrum nicht endgültig den Weg aus der IT in andere Bereiche gefunden. Fragen, die uns Business Coaches und Scrum Master, aber auch die Personalentwickler beschäftigen werden, kann ich an dieser Stelle nur anreissen, etwa:

welches sind die typischen Fallen und Erfolgsfaktoren beim ersten (!) Scrum-Projekt?
wie organisieren mehrere Scrum Teams ihre Zusammenarbeit, die Abhängigkeiten in Prozessen und Software regeln (Überschneidungen, gemeinsame Software-Komponenten etc.)?
Macht es Sinn, noch mehr Projektarten agil durchzuführen, z.B. Beratungsprojekte, Kundenprojekte, vielleicht sogar Infrastrukturprojekte?
Wie können „herkömmliches“ Projektmanagement (z.B. für alle Nicht-IT-Projekte) und agiles PM nebenher bestehen?
Wie gehen wir mit Begehrlichkeiten (ich will auch das neue agile Vorgehen!) und Enttäuschungen (früher war ich Projektleiter, jetzt nur noch Mitglied im Entwicklungsteam) umgehen?
Wie geht eine Belegschaft damit um, dass z.B. manche Teams räumlich sehr eng zusammen sitzen und arbeiten (Scrum) und andere Projektbeteiligte in verschiedenen Büros/Stockwerken/Gebäuden/Standorten sitzen?
Ist das überhaupt zu bewältigen, dass Scrum-Teams über mehrere Standorte hinweg für Projekte „zusammengezogen“ werden?

Was sind Ihre Erfahrungen und Fragen bei der Einführung von Scrum?

Sie haben dazu Anregungen, Ideen oder gar Antworten? Ich freue mich wie immer auf den Austausch mit Ihnen. Schreiben Sie mir an info@drblaschka.de

Foto: clipdealer