Hélène Valadon 16. Juni 2015

Agile im Konzern: So funktioniert’s in der Praxis

Agile Methoden erfolgreich implementieren ist Thema dieses Artikels. © depositphotos.com / chagin — © depositphotos.com / chagin

Management-Frameworks wie Scrum stellen Mitarbeiter in Konzernen vor große Herausforderungen: Die Teams stoßen immer wieder auf Widerstände an den Schnittstellen zur traditionellen Organisation. Wie sich dies vermeiden lässt und agile Methoden erfolgreich implementiert werden, erläutert Hélène Valadon, Executive Consultant bei Boris Gloger Consulting.

Vor 15 Jahren beschränkte sich der Einsatz von Scrum auf ein paar Teams, die meistens ein schlingerndes IT-Projekt retten mussten. Allenfalls ein paar wachsende IT-Firmen nutzten Scrum auch als Skalierungsmodell. Heute sind agile und leane Vorgehensweisen auch in Großkonzernen angekommen. Warum stößt der agile Ansatz dort auf Interesse? Umsatz und Gewinn dieser Unternehmen hängen in hohem Maß von den realisierten Projekten ab. Also erhoffen sie sich vom agilen Vorgehen, mehr Projekte mit den gleichen Ressourcen bewältigen zu können, das Projektportfolio fokussierter zu synchronisieren, die Transaktionskosten zu reduzieren und die Zuverlässigkeit von Projektabschlüssen zu gewährleisten. Zufriedene Kunden sind das Ziel.

Verbreiteten sich agile Methoden in den Anfängen ausschließlich nach dem Bottom-up-Prinzip (also von einzelnen Teams ausgehend), wird vor allem Scrum mittlerweile auch vom C-Level ins Spiel gebracht. Nach wie vor ergreift meistens die IT die Initiative, aber durch die enge Zusammenarbeit lassen sich andere Bereiche leicht anstecken.

Gegen starre Strukturen und Silodenken!

Ein typisches Beispiel aus der Praxis: Tom arbeitet seit zwölf Jahren in einem Konzern. Er hat als Projektleiter angefangen, war aber schon in vielen Abteilungen tätig. Vor ein paar Jahren hat er auf eigene Faust als Abteilungsleiter Scrum eingeführt – und es hat funktioniert. Tom hat gelernt, seinen Teams zu vertrauen, seine Mitarbeiter sind motiviert und engagiert wie noch nie. Aber es lässt sich nicht ignorieren, dass Toms Abteilung in eine Konzernstruktur eingebettet ist. Sie ist kein geschlossenes System im Luhmann’schen Sinne [1], ohne Interaktion mit anderen außerhalb seiner Grenzen! Im Gegenteil: Tom und seine Mitarbeiter kämpfen jeden Tag gegen die starren Strukturen und das Silodenken.

"Agile" bringt neue Arbeitsweisen und eine neue Sicht auf die Zusammenarbeit mit sich, getrieben von den Paradigmen des agilen Manifests [2]:

Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.
Funktionierende Software hat Vorrang vor umfassender Dokumentation.
Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
Eingehen auf Veränderungen hat Vorrang vor dem Befolgen eines Plans.

Diese Prinzipien in einem Konzern zu leben bedeutet, die Prozesse, vor allem aber die Kultur in Frage zu stellen und andere Wege für eine neue Art der Zusammenarbeit und Wertschöpfung in der gesamten Organisation zu suchen.

Nachfolgend nun einige Maßnahmen, mit denen es Tom sowie anderen Teams und Managern gelingt, die agilen Prinzipien im Konzern zu leben. Dabei handelt es sich nicht um ein gebrauchsfertiges Gesamtmodell oder Vorgehen, sondern um einzelne Maßnahmen, die im Laufe der Zeit die Unternehmenskultur tiefgreifend verändert haben. Nicht jeder hat die Chance, in großen Organisationen eine agile Revolution zu erleben, aber es geht auch in kleinen Schritten.

Bereichsübergreifende Kommunikation

Agile Vorgehensweisen stellen die direkte Kommunikation zwischen Individuen über komplexe, verordnete Prozesse. Eine der wichtigsten Maßnahmen ist daher, für Teams und Projekte einen Platz zu finden, an dem aktuelle Informationen visualisiert werden können. Manchmal steht dafür ein ganzer Raum zur Verfügung, manchmal ist es nur eine Wand. Wie in den "War rooms" von Google oder in Design Thinking Spaces finden die Mitarbeiter alle Informationen an einem Ort und diese Informationen werden vom Team selbst laufend aktualisiert – gut gepflegte Artefakte sind eine großartige Sache! Fast alle Meetings finden in diesen Räumen oder vor diesen Wänden statt, denn sie sind für die Teams und die Organisation die Instrumente, um kontinuierlich planen, entscheiden und Informationen austauschen zu können. Ein Releaseplan und/oder ein Taskboard helfen dabei, die Gruppen- und Arbeitsmeetings fokussiert und effizient zu halten.

Gut gepflegte Artefakte sind eine großartige Sache!

In Konzernen haben allerdings Lenkungsausschüsse oder Gremien die schwierige Aufgabe, Projekte völlig abstrakt steuern zu müssen. Ihre Informationen bekommen sie von Projektleitern, die jeweils für ein ganzes Team sprechen und anhand von integrierten Ergebnissen die Projektampel auf Grün, Gelb oder Rot stellen. Auch Tom wurde gezwungen, für ein Großprojekt einen Projektleiter zu ernennen, der mit dem Lenkungsausschuss kommunizieren sollte. Der Projektleiter verstand die für Scrum typischen Messungen nur in Ansätzen und versuchte, sie in die Darstellungen des traditionellen Projektmanagements zu pressen. Also kam es, wie es kommen musste: Es eskalierte und der Lenkungsausschuss war knapp davor, das Projekt zu stoppen. Die Hunderte PowerPoint-Folien und der fröhliche Grüne-Ampel-Bericht lieferten keine überzeugende Aussage darüber, wo das Projekt tatsächlich stand und wo es stehen sollte. Also bat Tom den Lenkungsausschuss, sich mit dem Team und den Product Ownern im Projektraum zu treffen. Dort erklärte er den Releaseplan, die Burndown-Charts [3] und das Impediment Backlog [4]. Zwei Stunden tauschten sich alle untereinander aus. Seit diesem Tag lädt Tom den Lenkungsausschuss regelmäßig zum Review ein – und alle machen mit!

Übergreifend synchronisieren und Abhängigkeiten bewältigen – Scrum of Scrums

Egal, wie groß ein Projekt ist: In der Regel müssen mehrere Teams und Abteilungen zusammenarbeiten und daher synchronisiert werden. Gibt es Abhängigkeiten zwischen den Lieferungen unterschiedlicher Teams und beeinflusst das die Release-Planung für ein Gesamtprodukt, setzen wir auf das Scrum of Scrums (SoS). In der Regel ist das ein tägliches Meeting, an dem Vertreter der jeweiligen Teams teilnehmen, um schnell auf Abhängigkeiten reagieren zu können. Dieses Meeting funktioniert auch zwischen verschiedenen Ebenen, zum Beispiel zwischen Product Ownern. Eine andere Variante sind themenspezifische SoS, um das gesamte Umfeld der Produktentwicklung einzubinden. Diese Art von Planungsmeeting kann für die zeitliche und inhaltliche Taktung zwischen Abteilungen eine schlanke und effiziente Lösung sein.

Dennoch haben viele Abteilungsvertreter am Anfang Schwierigkeiten mit dem SoS. Warum ist das so?

Jeder kommt mit unterschiedlichen Erwartungen oder sogar einer Hidden Agenda in das Meeting und verfolgt ausschließlich die Ziele der eigenen Abteilung.
Erfahrungsgemäß sinkt die Effizienz, je größer die Runde wird. Aus einem Austausch von Informationen wird die Übergabe von Informationen in eine Richtung – also eine andere Form des Reportings.

Ein wirklich funktionierendes Scrum of Scrums braucht daher ein anderes Mindset, eine andere Einstellung zueinander. Aus Betroffenen müssen Beteiligte werden.

"Wir planen zusammen" – das bedeutet: Ich habe eine Information, die der andere braucht. Und er hat eine Information, die ich brauche. Also sollten wir auch gemeinsam entscheiden.
Stille Teilnahme war gestern. Jeder Teilnehmer informiert die anderen darüber, was er braucht und was er anbieten kann.
Alle sollten davon ausgehen, dass nicht alles sofort entschieden werden kann. Da die teilnehmenden Personen nur Vertreter ihrer Abteilungen sind, müssen sie dort auch das Feedback und/oder das Commitment zu einer Entscheidung einholen.
Für das Scrum of Scrums sollte es einen Moderator geben, der an diese Prinzipien erinnert.

In unserer Beratungspraxis haben wir sehr gute Erfahrungen mit solchen Planungs-Meetings gemacht, um alle auf den gleichen Wissensstand zu bringen, damit sie optimal zum Projektzweck beitragen können. Diese Meetings helfen außerdem, die projektübergreifenden Impediments zu identifizieren.

Bereichsübergreifende Priorisierung und Anforderungsmanagement

Was die Arbeit mit Scrum so erfolgreich macht, ist die intensive Kommunikation in crossfunktionalen Teams einerseits und mit dem Kunden andererseits. In vielen großen Organisationen ist der Kunde ein Fachbereich, je nach Größe des Projekts sind es auch mehrere. Innerhalb des Konzerns haben diese Fachbereiche oft eine große Macht. Sie sind daran gewöhnt zu entscheiden, welche und manchmal wie viele Anforderungen zu implementieren sind. Wie im traditionellen Projektmanagement der Projektleiter wird in solchen Konstellationen der Product Owner zu einem „Proxy Product Owner“: Er hat keine Legimitation, die zu implementierenden Funktionalitäten zu priorisieren oder auszuwählen.

Was ist die Konsequenz? Häufig werden aus Eigennutz die falschen Entwicklungsprojekte ausgewählt, ohne die übergreifenden Prioritäten oder Abhängigkeiten der Systeme zu berücksichtigen. Die Studie „IT-Trends 2014“ von Capgemini zeigt, dass 50 Prozent der IT-Budgets von Fachbereichen für Features ausgegeben werden, die von der eigenen IT abgelehnt oder nicht umgesetzt werden. Das kann zu hohen Wartungskosten und Architekturproblemen führen.

Um das zu verhindern, ist es besonders wichtig, ein übergreifendes Anforderungsmanagement einzuführen – das ist alles andere als einfach und meistens der größte Kulturwandel. Die Lösung kann nur in der Zusammenarbeit der Product Owner liegen. Sie können es schaffen, die Themen pro Fachbereich übergeordnet zu priorisieren und sie dann auch fachbereichsübergreifend zu priorisieren. Ein Weg sind monatliche oder quartalsweise Priorisierungs-Workshops mit einzelnen und allen Fachbereichen. Noch einfacher wird diese übergreifende Priorisierung, wenn es in den Fachbereichen bereits Product Owner gibt.

Komplexität reduzieren

Während die Zahl und Größe durchzuführender IT-Projekte stetig steigt, stagniert die Quote erfolgreich abgeschlossener Projekte seit Jahren bei etwa 37 Prozent und sinkt sogar auf vier Prozent, wenn es um große Projekte geht [5]. Man geht davon aus, dass bei 70 Prozent aller Projekte der Zeitplan sowie die Kosten- und/oder Qualitätsziele nicht erreicht werden.

Ja, ein Projekt kann komplex sein. Aber man kann mit geringer Komplexität starten, indem man zunächst zum Beispiel zwei bis drei Teams zu je fünf bis sieben Personen einsetzt, die über die nötigen Kompetenzen verfügen. Nachdem diese Teams die ersten Erkenntnisse für die weitere Durchführung des Projekts gewonnen haben (z. B. in puncto Ressourcen, Architektur, Priorisierung, Rahmen für die Zusammenarbeit), kann skaliert werden.

Unternehmensweit umdenken

Die Anwendung von Scrum oder Kanban muss sich nicht auf die Softwareentwicklung bzw. IT-Abteilung beschränken. Muss denn eigentlich überall Scrum oder Kanban implementiert werden, um eine agile Organisation entstehen zu lassen? Natürlich nicht. Aber selbstverständlich hilft die praktische Erfahrung den Beteiligten, diese Methoden besser zu verstehen. Wir haben erlebt, dass Fachbereiche durch die Zusammenarbeit mit Scrum-Teams dazu inspiriert wurden, ihre eigene Arbeit ebenfalls auf einem Board zu visualisieren, sich jeden Tag zum Besprechen der Fortschritte zu treffen und sich gegenseitig zu helfen. Um die Rollen besser zu verstehen, haben Mitarbeiter der Personalabteilung die Rolle des Scrum-Masters übernommen. Selbst Stabsstellen wie das Qualitäts-, Portfolio- oder Testmanagement haben das agile Umdenken gewagt. Und wir haben auch schon Geschäftsführungen erlebt, die crossfunktionale Teams gebildet haben. Die Scrum-Master boten ihre Hilfe an, um die Freiwilligen bei ihren ersten Schritten zu unterstützen.

Übergeifender Austausch

Communities of Practice (CoP) oder Communities of Interest (CoI) bieten Raum für den Austausch und vor allem ermutigen sie, neue Ansätze auszuprobieren. Tom hat vor etwa einem Jahr eine CoP gegründet. Am Anfang kamen vor allem Scrum-Master, Projektleiter und Product Owner. Jedes Mal fiel Tom die Energie und das Engagement der Kollegen auf, die an den Treffen teilnahmen. Heute erweitern Abteilungs- und Gruppenleiter den Teilnehmerkreis. Sie wollen etwas Neues versuchen oder sich einfach über das Thema Agilität informieren. Spannend ist zu beobachten, welche Veränderung manche Mitarbeiter in solchen Communities oft vollziehen. Wenn sie sich endlich für ein Thema einsetzen können, das sie ausgewählt haben, oder wenn sie mit anderen eine Lösung für deren Probleme erarbeiten können, ist die Bereitschaft zur Kooperation beinahe unbegrenzt. Open Spaces sind eine gute Möglichkeit, um verschiedene Abteilungen zum Ausprobieren von Agile- und Lean-Ansätzen zusammenzubringen. Man kann sich mit Kollegen austauschen, die man sonst nie trifft und andere Blickwinkel aus der Organisation kennenlernen.

Was als informeller Austausch startet, kann sich im Laufe der Jahre zu einer stabilen agilen Bewegung entwickeln. Konzerne wie Volkswagen oder die Deutsche Telekom haben diese Erfahrung bereits gemacht. Je mehr Menschen im Konzern sich für Agile- und Lean-Themen interessieren, sich gegenseitig unterstützen und Best Practises identifizieren, desto größer ist die Chance, dass diese Methoden auch als Standard in Konzernprojekten anerkannt werden.

Lernende Organisation

Einzelne Manager, die Scrum oder Kanban in ihrem Bereich bereits erfolgreich eingeführt haben, warten oft verzweifelt darauf, dass der Rest der Organisation zu denselben Erkenntnissen kommt. Ihnen ist nicht bewusst, dass ihnen viele Plattformen zur Verfügung stehen, um von ihren eigenen Erfahrungen zu berichten. Die Mitarbeiterzeitung oder das Intranet sind wertvolle Kanäle, um die Kollegen zu erreichen. Tom hat zum Beispiel die Konzernzeitung genutzt, um die Agile- und Lean-Ansätze in Form einer Fallstudie bekannt zu machen. Seine Initiative hat zu einem ersten „Agile & Lean Tag“ geführt, an dem 150 Kollegen teilnahmen. Für solche Maßnahmen sollten die Projekte daher sorgfältig ausgewählt werden. Die gesamte Organisation sollte daraus lernen und neue Einsichten für Veränderungsinitiativen gewinnen können. Regelmäßige Retrospektiven [6] sind die beste Gelegenheit, um Ergebnisse zu sammeln, die an die Organisation kommuniziert werden können.

Zu einer lernenden Organisation gehört auch ein bewusster Umgang mit Fehlern und mit dem Scheitern. In Konzernen wird viel Wert auf Sicherheit und Planbarkeit gelegt und darin haben konstruktives Feedback, Lernen und kontinuierliche Verbesserung häufig keinen Platz. In Toms Abteilung sind kurze Feedbackrunden und das Identifizieren von Verbesserungsmöglichkeiten bereits zur Routine geworden. Und diese Routine nehmen er und seine Mitarbeiter einfach mit, wenn sie sich mit anderen Abteilungen treffen.

Mitarbeiter befähigen

Nur ein Mensch, der etwas Neues lernt, kann sich ändern. Ohne die beteiligten Menschen zu befähigen, werden die Erwartungen an neue Ansätze oder Vorgehensweisen kaum erfüllt werden können. Das klingt zwar logisch, in der Realität wird diese Tatsache aber gerne unterschätzt. Mit Scrum oder Kanban zurechtzukommen bedeutet nicht, lediglich die Prinzipien verstehen zu müssen. Dazu gehört vor allem die Art, wie man miteinander arbeitet, kommuniziert und sich organisiert. Ohne sich sowohl fachlich als auch methodisch weiterzuentwickeln, wird das nicht funktionieren. Wichtige Themen sind u. a. Servant Leadership, Lean Product Development, Agile Software Engineering, Test und Testautomatisierung, Design Thinking, Moderationstechnik und Teamentwicklung.

Nur ein Mensch, der etwas Neues lernt, kann sich ändern.

Für die Weiterbildung sollte daher ein gewisses Budget zur Verfügung stehen und am besten wird auch die Personalabteilung eingebunden, um das Angebot entsprechend anzupassen. Auch die Weiterbildung kann wiederum bereichsübergreifend gestaltet werden.

Topmanagement einbinden

Tom hatte ein anderes Problem: Wie konnte er das Topmanagement davon überzeugen, mitzumachen und das neue Vorgehen zu unterstützen? Wir hatten Glück: Auf der einen Seite interessierten sich sowohl die IT als auch ein Fachbereich bereits dafür. Auf der anderen Seite wollte das Management auf Erfahrungen oder bekannte Modelle zurückgreifen können. Nach dem Motto: Wir implementieren schnell einen geprüften Prozess und sparen uns dadurch die Konfrontation mit den Mitarbeitern und mit uns selbst. Dieser Ansatz scheitert in der Regel.

So verständlich die Unsicherheit und das Bedürfnis, sich auf Modelle stützen zu wollen, auch sein mögen, so warne ich trotzdem vor Blue Prints. Jede Organisation sollte ihren eigenen Weg entwerfen. Modelle bieten die trügerische Illusion, etwas Abstraktes – wie etwa von anderen durchgeführte Projekte oder mechanistisch komplexe Systeme – beherrschen zu können. Es gibt verschiedene Skalierungsmodelle, die eine gute Orientierung für Abläufe, die Organisation einer Abteilung oder das Produktportfolio geben. Es gibt aber kein Modell dafür, wie die Linienorganisation angepasst werden soll. Die Prinzipien sind bekannt, aber die Umsetzung muss individuell gestaltet werden, da es enge Zusammenhänge mit der Unternehmenskultur gibt.

Es ist nicht falsch, in Modellen zu denken, wenn man sich dabei bewusst ist, dass es Erklärungsmodelle sind. Modelle zeigen etwas auf, sie sind Landkarten der Realität – aber sie sind nie die Realität. Dem Management bieten Modelle Sicherheit, weil es damit die Abstraktion verstehen kann. Es kann sich wieder mit dem "System" befassen, statt mit den Menschen und ihren komplexen Herausforderungen. Für Tom war es wichtig, dass sich das Management mit den realen Problemen konfrontiert, denn Lösungen sind nur in der Zusammenarbeit mit den Kollegen zu finden. Daher war es unser Ansatz, uns zunächst in die Ist-Situation einzuarbeiten und unsdann stufenweise (inkrementell) anzupassen. So trafen wir das Portfolio-Management, Enterprise Governance, das Projektmanagement-Office etc. Wir haben "Sponsoren" innerhalb des Managements identifiziert und mit ihnen und den betroffenen Kollegen Lösungen erarbeitet, Pilotprojekte identifiziert und Rahmenbedingungen angepasst.

Mut ist einer der wichtigsten Werte von Scrum

Immer mehr Abteilungsleiter wie Tom schaffen es, ihre Konzerne jeden Tag agiler zu machen, ohne dabei auf ein Top-down-Wunder zu warten. Alle genannten Maßnahmen tragen in großen Organisationen vor allem dazu bei, sich miteinander neu zu vernetzen und damit einen Rahmen zu schaffen, in dem Vertrauen und Interdisziplinarität aufgebaut werden können. Natürlich braucht es Geduld, bis diese Maßnahmen Früchte tragen. Es braucht den Mut, nicht aufzugeben und immer wieder Neues auszuprobieren. Mut ist einer der wichtigsten Werte von Scrum – und den brauchen Sie, um die Veränderung in Ihren Konzern zu tragen.