Agile Transformation in 4 Schritten

Man kann sich darauf verlassen: Wo immer heute Menschen aus verschiedenen IT-Organisationen miteinander ins Gespräch kommen, geht es früher oder später um die agile Transformation. Viele Unternehmen haben sich auf den Weg gemacht oder planen, Agilität organisationsweit einzuführen. Fragt man nach dem Warum, heißt es oft: „Weil es der Vorstand beschlossen hat“. Oder man hört: „Weil wir die Herausforderungen der Digitalisierung nur mit Agilität meistern können“.

Die erste Antwort mag uninspiriert, die zweite nach einer Floskel klingen. Tatsächlich sind beide Antworten aber ziemlich gut. Denn agile Transformation bedeutet eine komplexe Veränderung zu vollziehen, die nicht nur die IT-Organisation betrifft, sondern das gesamte Unternehmen und möglicherweise darüber hinaus auch die Zusammenarbeit mit externen Beteiligten an der Wertschöpfungskette. Ein Commitment des Managements ist eine notwendige Voraussetzung für das Gelingen einer Veränderung dieser Größenordnung. Und: Für traditionell geführte Unternehmen wird es immer schwerer, Innovationen so schnell umzusetzen, wie es erforderlich ist, um die herkömmlichen „Brick & Mortar“-Prozesse durch digitalisierte Abläufe zu ersetzen. Agilität wird zu einer wettbewerbsentscheidenden Eigenschaft einer Organisation.

Ein Change Prozess als Wegweiser

Agile Transformation bedeutet, einen nachhaltigen, unternehmensweiten, technologischen und kulturellen Wandel zu vollziehen – nicht als Big Bang, sondern nach einem definierten, iterativen Change Prozess. Im Bereich des Change Managements existieren mehrere Modelle, die man für die agile Transformation adaptieren kann. Dazu gehören das 8-Phasenmodell von John P. Kotter¹  und das 3-Phasen-Modell von Kurt Lewin². Letzteres ist die Grundlage für die nachfolgend dargestellte iterative Struktur eines Prozesses für die agile Transformation.

Der Prozess startet mit einem Vorbereitungsschritt. Er dient dazu,

• eine Vision der zukünftigen agilen Organisation zu entwickeln (Wie sieht das Unternehmen der Zukunft aus?),
• den Scope der agilen Transformation zu definieren (Wer ist betroffen?),
• die Rückendeckung durch das Management zu sichern.

Daran schließen sich vier iterative Schritte an:

• das Analysieren, Planen und Vorbereiten konkreter Transformationsschritte,
• ihre Implementierung sowie
• das Verankern, Messen und kontinuierliche Verbessern der eingeführten Änderungen.

Die Rahmenbedingungen für die agile Transformation können sich im Laufe der Zeit verändern. Deshalb sollte man – bevor die Schritte 1 bis 3 erneut durchlaufen werden –

• Vision und Scope überprüfen.

Mit jeder Iteration wird die Agilität innerhalb der Organisation weiter skaliert.

Ein iterativer Change Prozess – zugeschnitten auf die agile Transformation

Nicht an agilen Inseln stranden

„Köpfe bewegen“ ist die zentrale Aufgabe bei der agilen Transformation. Die Schritte 1 und 2 dienen unter anderem auch dazu, Lernprozesse in Gang zu setzen, die zu neuen organisatorischen Strukturen und zu verändertem Verhalten der einzelnen Mitarbeiter, der Teams und des Managements führen. Die Verhaltensänderungen sind ein Maß dafür, wie weit die Transformation vorangeschritten ist.

Kein Wunder also, dass viele Unternehmen, bevor sie sich grundsätzlich für die agile Transformation entscheiden, agile Techniken zunächst im Kleinen erproben. Im Bereich der Softwareentwicklung sind es manchmal sogar einzelne Teams bzw. ihre Projektverantwortlichen, die aus eigener Initiative beispielweise Scrum ausprobieren. Läuft so ein Pilotprojekt gut, kommen weitere kleine Projekte hinzu – noch bevor eine grundsätzliche Entscheidung zur agilen Transformation getroffen wurde.

Fehlen zentrale Vorgaben für die Pilotprojekte, dann schafft dieses Vorgehen, so naheliegend es auch sein mag, neue Hürden für die agile Transformation. Scrum ist ein Framework, das unterschiedlich ausgeprägt werden kann. Überlässt man das jedem einzelnen Team, kann also jedes Team frei wählen,

• wie es seine Epics, Features und User Stories verwaltet und welche Tools es dazu einsetzt,
• welche Priorisierungsverfahren und Schätzmethoden es benutzt,
• welche Metriken es zur Messung seiner Geschwindigkeit und des Projektfortschritts verwendet,
• wie es Transparenz schafft und mit den Stakeholdern kommuniziert,

dann entstehen Inseln mit eigener agiler „Kultur“. Auf der einen wird in Story Points geschätzt, auf der anderen in Personentagen. Die „Bewohner“ einer Insel arbeiten mit Post-its, die einer anderen nutzen MS Excel. Wieder andere setzen eine App oder ein günstiges Cloud-basiertes Tool zur Verwaltung von User Stories ein. Vergleichbarkeit und Nachvollziehbarkeit der Projekte – das zeigen schon diese wenigen Beispiele – bleiben dabei auf der Strecke. Aussagen darüber, wie performant die gesamte Organisation ist (zum Beispiel gemessen an der Zahl der realisierten Anforderungen pro Zeitraum), können nur schwer getroffen werden. Der oben skizzierte Change Prozess für die agile Transformation sieht deshalb explizit vor, die möglicherweise entstandenen agilen Inseln zu identifizieren und aufzulösen. Denn: Ja, Pilotierung muss sein. Aber die Schritte

• von einem auf viele agile Projekte sowie
• von kleinen auf große agile Vorhaben

müssen auf einem einheitlichen Konzept für die einzusetzenden Methoden und die Tool-Infrastruktur basieren.

Eine Weile hybrid fahren

Planung und Steuerung großer Projekte stellen im Verlauf der agilen Transformation eine besondere Herausforderung dar. In Unternehmen, die die agile Transformation stufenweise angehen, also zum Beispiel zunächst die Softwareentwicklung umstellen, beim Rollout und Betrieb von Softwaresystemen aber noch klassisch vorgehen, besteht der Bedarf nach hybridem Projektmanagement. Dabei wird ein großes Projekt zwar im Wesentlichen anforderungsorientiert geplant und in Releases und Sprints mit fester Dauer durchgeführt. Das Projekt umfasst aber auch Aufgaben, die aktivitätsorientiert mit Work Packages und Meilensteinen geplant werden. Für diese hybriden Projekte werden eine integrierte Planungstechnik und wirksame Instrumente für das Controlling benötigt, beispielsweise Charts und Key Performance Indikatoren mit einem Scope für mehrere parallel arbeitende Teams und alle geplanten Releases und Work Packages.

Der Projektplan eines hybriden Projekts in objectiF RPM

objectiF RPM als Reisebegleiter auf dem Weg der agilen Transformation

Unternehmen, die sich auf den Weg der agilen Transformation machen, werden Phasen erleben, in denen gleichzeitig agile, hybride und klassisch aktivitätsorientiert geplante Projekte laufen. Es wird zur gleichen Zeit Projekte geben, die Anforderungen modellieren, formularbasiert beschreiben und klassisch in Aktivitäten einplanen, und andere, die mit User Stories, Backlogs und User Story Boards arbeiten. Um eine Road Map aller laufenden und geplanten Projekte zu erzeugen und Aussagen über die „Performance“ der gesamten Organisation zu gewinnen, ist es vorteilhaft, alle Projekte – egal ob klassisch, agil und hybrid – mit einem Werkzeug zu steuern, das eine skalierbare Infrastruktur für alle Projekte bietet.

Genau das ist die Idee hinter unserer ALM-Software objectiF RPM. Welche Instrumente objectiF RPM für die Planung und das Controlling klassischer, agiler und hybrider Projekte anbietet, haben wir in einem Whitepaper ausführlich dargestellt:

Schauen Sie doch einmal hinein. Viel Spaß beim Lesen.

Quellen:
[1] John P. Kotter: Leading Change: Wie Sie Ihr Unternehmen in acht Schritten erfolgreich verändern, Verlag Vahlen, 2011.
[2] https://de.wikipedia.org/wiki/3-Phasen-Modell_von_Lewin