Agile Transformation

Wir möchten heute mit Ihnen eine Geschichte aus unserer Praxis teilen, die Ihnen vielleicht Anregungen gibt, wenn Sie dabei sind, Ihr Unternehmen in die Agilität zu führen. Wir stellen Ihnen die Geschichte eines Projektmanagers aus einem etablierten Unternehmen vor, das im Technikbereich auf 30 erfolgreiche Jahre zurückblickt, ca. 3000 Mitarbeiter beschäftigt und von der Zentrale in Deutschland aus weltweit tätig ist. Im Anschluss stellen wir Ihnen das ShuHaRi- Konzept als eine Möglichkeit für Ihre Veränderungsarbeit vor. Unser Gesprächspartner, nennen wir ihn Xaver, begleitet als Projektmanager aus dem IT-Bereich

verschiedene Projekte in der Produktion und den indirekten Bereichen. Sein Aufgabenbereich umfasst interne Trainings sowie Ausbildungen zum Green Belt und Yellow Belt. Er ist weltweit aktiv und arbeitet mit verschiedenen Abteilungen zusammen. Hier beantwortet er unsere Fragen:

Wie war Dein Start in die Welt des agilen Projektmanagements?

Ich begleite seit fünf Jahren ein Projekt in der Produktion, hier soll ein neues Arbeitssystem implementiert werden. In dem Projekt arbeiten wir nach dem Wasserfall-Modell (ein lineares Vorgehensmodell für das Management von Projekten). Die

Projekt-Verantwortlichen für den Bereich der IT-Umsetzung haben jedoch immer bekräftigt, dass sie nach dem Scrum-Modell arbeiten (in sogenannten Sprints, in denen mehrere Themenbereiche bearbeitet, getestet und abgeschlossen werden. Ein Sprint dauert zwei bis vier Wochen). Trotz des angeblich agilen Vorgehens machte das Projekt über einen längeren Zeitraum keine nennenswerten Fortschritte und ich fragte mich: warum?

Was war Dein nächster Schritt?

Ich beschloss also, mich selbst mit dem Konzept der Agilität und den Prinzipien und Werten, die hinter dem Scrum-Framework

stehen, auseinanderzusetzen und besuchte das CETPM-Seminar "Agile Basics". Dabei erkannte ich, dass unser Team nicht nach Scrum arbeitete: „Wir sagen, dass wir Scrum machen, tun es aber nicht“. Mit dieser Erkenntnis kehrte ich an meinen Arbeitsplatz zurück und versuchte selbst, die Prinzipien und Werte aus dem agilen Manifest und das Scrum-Framework in unser laufendes Projekt zu implementieren. Wie konnten wir die Scrum-Meetings integrieren, wer konnte welche Scrum-Rolle übernehmen und wie konnte ich in diesem Projekt meine Rolle vom klassischen Projektleiter hin zu einem agilen Product Owner gestalten?

Wie gut hat das funktioniert?

Es hat wenig gut funktioniert bei der Umsetzung und es gab viele Hindernisse. Die Scrum-Welt war ein Novum im Unternehmen. Die Beteiligten hatten wenig Ahnung von Scrum. Ich stieß auf Widerstand, weil die Menschen sich nicht verändern wollten. Immer wieder hörte ich: „So schlecht ist es nicht wie wir arbeiten“… Doch ich wollte nicht aufgeben und meldete mich bei der CETPM Veranstaltung "Agile Werkstatt" an. Dort hatte ich Gelegenheit zum Austausch mit Kollegen aus ganz Deutschland. Ich erhielt im gemeinsamen Arbeiten wichtige Impulse für meine Probleme: Ich hatte jetzt neue Ideen wie ich noch an die Sache herangehen konnte und an welchen Schrauben ich dafür drehen musste. Hoch motiviert kehrte ich an meinen Arbeitsplatz zurück und versuchte es erneut... und wieder scheiterte ich.

Woran lag es, dass Du erneut mit Deinen Ideen gescheitert bist?

Das Scheitern lag nicht an den Tools – der größte Widerstand kam durch das Mindset der Menschen. Ihnen fehlte der Wille und der Mut, etwas Neues auszuprobieren. Leider erhielt ich auch von Seiten der Führungsebene nicht die von mir eingeforderte und dringend benötigte Unterstützung.

Was hast Du dann noch unternommen, um das agile Framework bei Euch im Projekt erfolgreich zu implementieren? Als ich darüber nachdachte, warum ich nicht weiterkomme, kam mir der Zufall zur Hilfe. Aufgrund des hohen Arbeitsanfalls wurde in der Abteilung ein Freelancer als zusätzliche Unterstützung des Teams geholt. Dieser neue Kollege hatte langjährige IT-Erfahrung und brachte zusätzlich umfangreiche Erfahrung mit dem Scrum-Framework mit. Schon bald stellte ich fest, dass ich in ihm einen Verbündeten gefunden hatte.

Was ist danach bei Euch in der Organisation passiert?

Der neue Mitarbeiter merkte sofort, dass wir nicht nach Scrum arbeiteten und forderte die Verantwortlichen auf, das Scrum-Framework professionell umzusetzen und begann sofort mit den notwendigen Veränderungen. Er etablierte gemeinsam mit dem Team ein ordentliches Product Backlog, sorgte dadurch für mehr Transparenz im Projekt und etablierte die notwendigen Scrum-Meetings (Daily Scrum, Sprint, Review, Sprint Retrospektive).

Welche systemischen Veränderungen waren dadurch möglich?

Langsam haben sich die Dinge verändert und wir etablierten im Team mehr und mehr agile Elemente. Dabei veränderte sich auch das Mindset der Teammitglieder spürbar. Woran glaubst Du liegt es und oder lag es, dass eine professionelle Umsetzung der agilen Projektmanagementstruktur zu Beginn nicht möglich war? Ich hatte ja zu diesem Zeitpunkt bereits selbst viel Energie reingesteckt und konnte leider keine messbaren Erfolge erzielen. Die fehlende externe Unterstützung durch einen Scrum-Master mit viel Erfahrungswissen war hier ein zentraler Faktor. Der neutrale Blick von außen auf unsere gewachsene Projekt-Konstellation war das entscheidende Element, das gefehlt hatte.

Gibt es etwas, dass Du uns abschließend noch mit auf den Weg geben möchtest?

Ja sehr gerne. Erstens sollte man sich rechtzeitig externe Hilfe holen. Zweitens braucht es Mut zur Veränderung, man muss sich trauen, neue Dinge auszuprobieren, Fehler zu machen und daraus zu lernen. Drittens ist es sehr wichtig, zu Beginn das Scrum-Framework zu erlernen und dann konsequent umzusetzen.

Wir danken Xaver für diese Einblicke in seine Erfahrungen bei der Einführung von Agilität. Nun geht es weiter mit der Frage: Was sind mögliche Zutaten für die erfolgreiche Veränderungsarbeit mit Scrum?

ShuHaRi

In der agilen Gemeinschaft ist Shu-Ha-Ri ein Konzept, mit dem wir den Fortschritt unserer Reise hin zu einer neuer Arbeitsweise erfassen können. Alistair Cockburn (Mitbegründer des agilen Manifests) machte das Prinzip in der agilen Softwareentwicklung populär. Was steckt hinter dem Konzept und warum ist es bei der Veränderungsarbeit und Einführung von SCRUM so wichtig?

Der Ursprung des Konzeptes stammt aus der japanischen Kampfkunst Aikido. Aikido-Meister Endō Seishirō Shihan erklärt die Idee wie folgt:

„Es ist bekannt, dass wir, wenn wir etwas lernen oder trainieren, die Stufen von Shu, Ha und Ri durchlaufen. Diese Stufen werden wie folgt erklärt. Im Shu wiederholen wir die Formen und disziplinieren uns, so dass unser Körper die Formen aufnimmt, die unsere Vorfahren geschaffen haben. Wir bleiben diesen Formen treu und weichen nicht von ihnen ab. Sobald wir uns diszipliniert haben, um uns die Formen und Bewegungen anzueignen, führen wir in der Ha-Stufe Neuerungen ein. In diesem Prozess können die Formen gebrochen und verworfen werden. In Ri schließlich entfernen wir uns vollständig von den Formen, öffnen die Tür zur kreativen Technik und gelangen an einen Ort, an dem wir ungehindert nach dem handeln, was unser Herz/ Geist wünscht, ohne dabei die Gesetze zu überschreiten.“

Jeff Sutherland, der Mitbegründer von Scrum, lehnte sich an diese Konzepte an, um die drei Stadien der Scrum Mastery und ihre Progression zu beschreiben. Er hat die gleichen Stufen identifiziert, die ein Scrum Master und sein Team durchlaufen müssen, um eine tiefere Beherrschung der Praxis zu erreichen:

Shu (doing agile)

Im Shu-Zustand ist der Scrum Master der Meister des Prozesses, des Scrum-Frameworks. Er übernimmt die Führung des Teams: Er richtet Veranstaltungen ein und moderiert diese. Er hilft seinem Team, einen stabilen Zustand zu erreichen, ein gutes Arbeitstempo zu finden und leitet die kontinuierliche Verbesserung durch den Prozess der Retrospektive. In diesem Zustand liegt der Schwerpunkt eher darauf, wie man etwas erreicht, ohne sich zu sehr um die zugrunde liegenden Theorien zu kümmern.

Ha (becoming agile)

Wenn der Scrum Master und sein Team den Ha-Zustand erreichen, erkennen wir dies an ihrer Arbeitsweise mehr als an dem Ausführen einzelner vorgeschriebener Schritte. Das Team hat gelernt, am Ende eines Sprints ein fertiges Inkrement zu präsentieren, es hat ein fertiges Product Backlog, das von einem Product Owner verwaltet und priorisiert wird, es hat die eigene Produktivität mindestens verdoppelt und es hat starke Unterstützung durch das Management.

Ri (being agile)

In dieser Phase kann der Scrum Master zurücktreten und das Team, einen gut funktionierenden und produktiven Organismus, sein Bestes geben lassen. Der Scrum Master steht nicht mehr im Rampenlicht, passt sich instinktiv und nahtlos an die Umgebung und die Bedürfnisse des Teams an und unterstützt nur noch sporadisch. In der Realität erleben wir selten Scrum Master, die innerhalb des Teams kontinuierlich in einem Ri-Status agieren. Oft starten agile Teams mit einem internen Scrum Master ohne Erfahrung und bestehende Projektleiter werden zum Product

Owner ernannt. Den Grund dafür können wir nur mutmaßen. Teamentwicklung verläuft oftmals nicht geradlinig. Teams sind lebende Organismen. Organismen haben gute und schlechte Tage. Sie werden krank, und sie heilen. Teams sind nicht anders. Sie entwickeln sich weiter, sie verbessern sich, sie erreichen neue Höhen und sie machen Rückschritte. Wie also kann ein Scrum Master den schwer fassbaren Ri-Status erreichen und halten?

Alistair Cockburn sagt in "Heart of Agile", dass Ri-Leute im Allgemeinen nicht sagen können, wie sie sich im Moment für eine Technik entscheiden, weil sie so tief verwurzelt und unmittelbar ist. Im Sinne des allgemeinen Wissenserwerbs entspricht Ri dem "Erfinden und Mischen von Techniken". In Anlehnung an Martin Broadwells vier Kompetenzstufen entspricht der Ri-Status in etwa der unbewussten Kompetenz. Und dazu benötigt es viel Erfahrungswissen.