Wählen Sie Ihre Sprache

Den Roll-out agiler Methoden erfolgreich meistern

Den Roll-out agiler Methoden erfolgreich meistern

DER ERFOLGREICHE ROLL-OUT VON AGILITÄT FUNKTIONIERT NICHT ZUFÄLLIG: ES BRAUCHT EIN SKALIERUNGSMODELL, EINE ROADMAP UND RICHTIG STARKES STAKEHOLDER- BZW. CHANGE-MANAGEMENT von Wojciech Bolesta, TMG CONSULTANTS

Mit agilen Ansätzen und Methoden wie Scrum oder Kanban lässt sich die Performance in operativen Entwicklungsteams um 20 bis 30 Prozent verbessern. Was die Praxis allerdings auch immer wieder zeigt: Allein auf der operativen Team-Ebene Agilität zu praktizieren, reicht keinesfalls aus, um die Leistungsfähigkeit im Produktentstehungsprozess (PEP) insgesamt deutlich zu steigern. Nach einer erfolgreich verlaufenen Pilotierung gilt es daher, ein zielführendes Vorgehen für die Ausbreitung der agilen Methoden im Unternehmen zu erarbeiten und konsequent umzusetzen. Damit dieser Roll-out übergreifend gelingt und das vorhandene Verbesserungspotenzial im PEP bestmöglich ausgeschöpft werden kann, ist neben einem klaren Vorgehenskonzept auch ein professionelles Management der Veränderung unerlässlich: Von Beginn an gilt es, Betroffene zu Beteiligten zu machen und bei ihnen gleichzeitig Kopf, Herz und Hand zu adressieren.

Bestens – der erste oder die ersten zwei Piloten sind richtig erfolgreich verlaufen. Entweder im Rahmen eines sehr überschaubaren Projektes mit nur einem operativen Entwicklungsteam, oder aber in einem komplexeren Projekt, wobei aber in der Regel „nur“ eines der Entwicklungsteams (SW oder HW) mit agilen Arbeitsweisen verprobt wurde.

Nun steckt das Management in einem echten Dilemma. Einerseits hat man am zuvor definierten Beispiel erleben können, dass Performance und Motivation in den Teams massiv gestiegen sind. Anderseits ist man gleichzeitig mit mindestens zwei echten Herausforderungen konfrontiert.

Zum einen Unsicherheit: Liefert die neue Arbeitsweise auch in großen, komplexen und lokal verteilten Projekten bessere Ergebnisse? Funktioniert sie auch bei einer hohen Anzahl paralleler Projekte? Und vor allem: Lassen sich neue Rollen, Team-Empowerment etc. auch mit der bestehenden Aufbauorganisation erfolgreich in Einklang bringen?

Zum anderen sind es die im Piloten aufgetretenen Schwierigkeiten an den Schnittstellen (siehe hierzu Abbildung 1): Ein Teil des Unternehmens arbeitet nun signifikant anders als die restliche Organisation. An den Schnittstellen kommt es folglich zu Reibungsverlusten, unter anderem in Form von erhöhtem Abstimmungsaufwand. Wo genau und wie stark diese Themen auftreten, hängt weitgehend von der unternehmensindividuellen Situation ab.

 

Abbildung 1:
Typische Schnittstellenprobleme beim Aufeinandertreffen von agilen Arbeitsweisen mit klassischen Strukturen und Abläufen

Der Roll-out-Lösungsansatz der TMG beinhaltet dementsprechend die Erarbeitung eines sogenannten Skalierungs-Frameworks, also die konzeptionelle Beschreibung zum Adressieren der erwähnten Unsicherheiten, bzw. die Beantwortung der Frage, wie die komplette heutige Projektlandschaft im Einklang mit der Aufbauorganisation abgewickelt werden kann.

Darüber hinaus braucht es eine Roadmap, die aufzeigt, welche Projekte in welcher Reihenfolge in die agilen Arbeitsweisen „überführt“ werden. Mit voller Power und Stringenz zu agieren, ist hierbei wichtig. Der Zeitraum zwischen dem ersten erfolgreich verlaufenen Pilot-Projekt und der in weiten Teilen der Organisation geänderten Arbeitsweise muss so kurz wie möglich gehalten werden. Das heißt: die für den Roll-out Verantwortlichen müssen einen klaren Fahrplan haben, welche Projekte mit höheren Komplexitätsgraden kurzfristig angegangen werden, um damit die Eignung und Nützlichkeit der neuen Arbeitsweise weiter zu belegen und weitere Erfolgsgeschichten zu schreiben. Als sehr geeignetes Folgeprojekt nach dem ersten „kleinen“ Piloten hat sich beispielsweise eine interne Plattformentwicklung bewährt: hohe Komplexität gepaart mit einem gewissen Freiheitsgrad in Bezug auf die Anforderungen.

Dabei wird der Roll-out nur mit hundertprozentiger Rückendeckung durch das Management funktionieren: jeder im Unternehmen muss erkennen können, dass die Führung voll und ganz hinter dem Vorhaben steht und ein neues „Zeitalter“ in der Produktentstehung anbricht. Geschieht dies nicht, gibt es für Skeptiker, Opponenten und eingefleischte Veränderungsverweigerer immer die Möglichkeit, jegliche Schritte in Richtung Agilität zu konterkarieren – bis das oberste Management irgendwann resigniert, nach dem Motto: „Wir haben’s ja probiert, es hat aber nun mal nicht funktioniert“.

Skalierungs-Framework für den gesamten Produktentstehungsprozess

Für die Herausforderung, Agilität von einem erfolgreichen Piloten ausgehend in eine Organisation auszurollen, gibt es im Markt bereits diverse Standard-Skalierungsmodelle – namentlich Large Scale Scrum (LeSS), Scrum@Scale, Scaled Agile Framework (SAFe) und Disciplined Agile 2.0 (ehemals Disciplined Agile Development DAD). Allen Modellen ist gemein, dass sie sich im Wesentlichen auf die Software-Entwicklung fokussieren. Im Hinblick auf weitergehende Anforderungen sind diese Modelle nach unserer Einschätzung recht limitiert. Unabhängig von den begrenzten Einsatzmöglichkeiten halten wir es aber auch aus einem anderen Grund nicht für sinnvoll, mit Standard-Frameworks zu arbeiten: Die Akzeptanz bei den Teams ist nach aller Erfahrung deutlich geringer als bei einem Framework, das individuell auf die Belange des Unternehmens zugeschnitten wird.

Jedes Unternehmen hat eigene, einzigartige Rahmenbedingungen – dies gilt insbesondere im Hinblick auf die Branche, vor allem aber auf Mitarbeiter, Identität und Kultur. Diese Individualität gilt es, bei der Skalierungsmethode in passender Weise zu berücksichtigen und abzubilden. Insofern sollten die Roll-out-Verantwortlichen die Standard-Frameworks zur Skalierung agiler Methoden zwar kennen, aber nicht dogmatisch anwenden: Wir raten unseren Kunden jedenfalls dazu, von den Standard-Frameworks nur jeweils diejenigen Elemente zu nutzen, die das eigene Unternehmen wirklich weiterbringen, und die Skalierung grundsätzlich auf Basis eines selbst entwickelten individuellen Frameworks anzugehen. Dieses sollte sowohl die Prozess- als auch Organisationsaspekte des gesamten Produktentstehungsprozesses mit einbeziehen.

Für die Entwicklung eines eigenen Skalierungsmodells empfehlen wir, ein cross-funktionales Workshop-Team aus qualifizierten Mitarbeitern zu bilden und für etwa 1 bis 2 Wochen ungestört an dieser Aufgabe arbeiten zu lassen. Dabei ist es wichtig, dass die Mitarbeiter die Grundlagen von Agilität verstehen und die zahlreichen agilen Elemente im Sinne der möglichen Bausteine eines eigenen Frameworks kennenlernen. Bewährt hat sich daher, diesem Team einen erfahrenen externen Moderator bzw. Berater zur Seite zu stellen. Dessen vorrangige Aufgabe besteht darin, das Team mit seiner Expertise in Bezug auf Agilität, Methoden-Know-how und Einschätzungen im Hinblick auf die unterschiedlichen Nutzungs- und Wirksamkeitsaspekte der verschiedenen agilen Elemente zu unterstützen. Wer so vorgeht, erhält am Ende des Tages eine pragmatische, erfolgversprechende und implementierbare Skalierungs-Lösung, die von den Teams voll und ganz akzeptiert wird: schließlich haben die Team-Member diese Form der Skalierung selbst kreiert. Ein erstes Commitment für das Skalierungsvorgehen ist damit in der Organisation verankert.

Richtiges Projekt-Setup ist erfolgskritisch

Ob eine Skalierung agiler Methoden erfolgreich gestaltet werden kann, entscheidet sich bereits gleich zu Beginn eines solchen Vorhabens: beim Bilden der Teams und der Festlegung klarer Verantwortlichkeiten. Auch hierfür gibt es keine allgemeingültige Blaupause, sehr wohl allerdings Strukturen und Prozesse, die sich in der Praxis bewährt haben.

Nachfolgend möchten wir beispielhaft das Projekt-Setup und die weitere TMG-Vorgehensweise anhand eines Projektes skizzieren, bei dem von den „Hardwerkern“ in der Entwicklungsabteilung eines Automobilzulieferers der Wunsch geäußert worden war, agiler entwickeln zu wollen, nachdem sich bei ihren Software-Kollegen bewiesen hatte, wie gut agiles Arbeiten funktioniert. Die Besonderheit bei dieser Form der kombinierten agilen Entwicklung war, dass die Hardware-Seite trotz agilen Arbeitens im klassischen V-Modell – mit all seinen unverrückbaren Meilensteinen – gefangen bleibt.

Um den skizzierten Anforderungen gerecht werden zu können, wurden folgende Teams gebildet:

  • das Core-Team, cross-funktional zusammengesetzt mit Vertretern aus allen für das Projekt relevanten Bereichen
  • das Requirements-Team: Hierbei handelt es sich im Prinzip um eine kollokierte Stabsstelle des Core-Teams, zuständig für das Requirements Management bzw. für die inhaltliche Steuerung (ähnlich einem Systems Engineering Team). Aufgabe dieses Teams ist es unter anderem, vorbereitende Arbeiten zu übernehmen, die dem Core Team die Entscheidung erleichtern, welche Themen von welchem Hardware- und Software-Team als nächstes angegangen werden sollen
  • Disziplinen-Teams: jeweils reine, unvermischte Teams aus Software-Entwicklern, Hardware-Entwicklern und Testern
  • Fokus-Teams: deren Aufgabe besteht darin, im Vorhinein als besonders komplex, zeitkritisch und/oder technologisch anspruchsvoll eingeschätzte Themenaspekte separat zu bearbeiten und voranzutreiben. Mit der Bildung dieser – ebenfalls cross-funktional zusammengesetzten – Teams wurde verhindert, dass das Core Team durch besonders heikle Aufgaben überbeansprucht und in seiner Leistungsfähigkeit beeinträchtigt wird

Wie es die agilen Methoden erfordern, wurde das gesamte Anforderungspaket in überschaubare Tranchen zerlegt und von den jeweiligen Teams in kurzen Iterationen und inkrementellen Schritten abgearbeitet. Die Software-Teams nutzten dabei durchwegs Scrum. Die Hardware-Teams zogen es demgegenüber vor, mit der Kanban-Methode zu arbeiten.1.

1 - Wie sich der Prozess der Hardware-Entwicklung mit gezielt eingesetzten agilen Methoden deutlich beschleunigen lässt, wird im Artikel „Auch die Hardware-Entwicklung profitiert von agilen Methoden“ ausführlich erläutert.

Agile Elemente in den klassischen V-Zyklus einbauen

Wie bereits kurz angedeutet, konnte und sollte in dem Projekt nicht am klassischen V-Zyklus gerüttelt werden. Durch Nutzung agiler Elemente im Entwicklungsprozess ergibt sich allerdings die Möglichkeit, die Arbeiten der verschiedenen Teams wesentlich häufiger über den V-Zyklus verteilt zu synchronisieren, als dies bei der bisherigen Arbeitsweise der Fall war.

 

Abbildung 2:
Agile Methoden synchronisiert im übergeordneten V-Modell

Anpassungsfähigkeit und Flexibilität konnten durch das kurzfristige Rückkoppeln erkennbar gesteigert werden. Im nächsten Schritt wird jetzt zu prüfen sein, inwieweit es gelingen kann, in Zukunft noch mehr Agilität in den V-Zyklus zu bringen. Die Zukunftsvision geht übrigens dahin, über ein zielführendes Schneiden und Abmischen der Requirements und Steuern der Komplexität einen im Vergleich zu heute deutlich kürzeren, aber in der Durchlaufzeit standardisierten V-Zyklus zu gestalten. Die Anzahl der V-Zyklen wird zunehmen, der Prozess insgesamt allerdings deutlich weniger Zeit beanspruchen, weil der höhere Grad an Agilität die Geschwindigkeit enorm steigert. In der Produktentwicklung wird man viel schneller und unter qualitativen Gesichtspunkten auch noch besser unterwegs sein.

Diese intelligente Steuerung der Anforderungen ermöglicht zudem die punktgenaue Synchronisierung der unterschiedlichen Durchlaufzeiten der Teams: während die Software-Teams im Prinzip beliebig schnell liefern können, haben Hardware-Entwicklungen aufgrund von physikalischen Rahmenbedingungen Mindestdurchlaufzeiten, an denen kurzfristig nur begrenzt optimiert werden kann. Daher ist es wichtig darauf zu achten, dass Software und Hardware in regelmäßigen und möglichst kurzen Abständen Synchronisierungspunkte im Sinne abgeschlossener Iterationen haben.

Projektlandkarte sorgt für Transparenz

Um jederzeit Transparenz zu gewährleisten und in einer Gesamtsicht aufzuzeigen, wie weit die einzelnen Teams im Entwicklungsprozess vorangekommen waren, wurde zudem eine sogenannte „Project Sync Map“ erarbeitet. Eine Art Projektlandkarte, auf der die wesentlichen „Deliverables“ dargestellt sind – die wichtigsten Hardware- und Software-Meilensteine –, allerdings in Form einer „physisch an der Wand“ visualisierten Darstellung, die es jedem Teammitglied und Verantwortlichen ermöglicht, sofort zu sehen, ob und wie sich die einzelnen Elemente zu einem Gesamtbild zusammenfügen. Das hat zwar nicht unbedingt etwas mit Agilität im definierten Sinne zu tun, sehr wohl aber mit einer deutlich verbesserten Transparenz.

Und die kommt den Teams in ihrer selbstverantwortlichen Arbeit zugute: Agil steuern kann bekanntlich nur, wer den aktuellen Projektstatus kennt. Konkret bedeutete dies in unserem Projekt zum Beispiel, dass wir Aufgaben, die beim ursprünglich angedachten Vorgehen als „nicht termingerecht realisierbar“ eingeschätzt worden waren, leicht anders zuschnitten und so auf die Teams umverteilten, dass die Termine wieder realistisch wurden. Ob diese Umsteuerung funktioniert, wurde wöchentlich verifiziert und in der realen Praxis überprüft.

Die Projektlandkarte ist ein enorm wichtiges Hilfsmittel, um die Arbeit der Teams zu synchronisieren. Hinzu kommt aber noch ein weiterer äußerst positiver Nebeneffekt: Wenn die anwesenden Teamvertreter regelmäßig vor dieser Wand stehen und persönlich ihr Commitment abgeben, den nächsten Meilenstein auf jeden Fall halten zu können, dann hat dies eine wesentlich größere Glaubwürdigkeit als das bis dato übliche unpersönliche „Häkchen setzen“ in einem der zahlreichen Formulare.

Lerneffekte durch regelmäßige Retrospektiven

Wichtig für den Erfolg ist ferner, auf allen Projektebenen regelmäßig Retrospektiven durchzuführen. In unserem Beispielprojekt haben die Teams nach jeder Iteration Bilanz gezogen und zugleich überlegt, was man als Team – basierend auf den bisher gemachten Erfahrungen – bei den nächsten Schritten noch besser machen kann und was man lieber lassen sollte, weil es sich nicht bewährt hatte. Alles, was von den Teams in der Retrospektive an Schwachstellen und Verbesserungspotenzialen identifiziert wurde, durften sie auch in Angriff nehmen. Themen, die sich auf der Team-Ebene allein nicht lösen ließen, wurden vom Scrum- oder Kanban-Master aufgenommen und an entsprechender Stelle im Unternehmen mit Nachdruck adressiert, um auch für teamübergreifende Probleme zeitnah eine zielführende Lösung zu finden.

Bei der Skalierung eines agilen Frameworks ist es unerlässlich, die gewählten Methoden zur kontinuierlichen Verbesserung so zu etablieren, dass sie den skalierten Anforderungen der Teams gerecht werden. Erkenntnisse und einzelne „Best Practices“ müssen effizient in die anderen Teams zur Nachahmung getragen und übergreifende, an verschiedenen Stellen auftretende Probleme durch Synchronisierung gemeinschaftlich gelöst werden können. Entsprechende Medien und Gremien, wie zum Beispiel „Scrum Master Meetings“, müssen hierzu etabliert und nachhaltig genutzt werden.

Professionelles Stakeholder-Management ist unerlässlich

Die Einführung von Agilität und die Skalierung im Projekt bzw. im Unternehmen erfordern echtes Umdenken auf allen Ebenen. Überall gibt es unterschiedliche Interessen, Erwartungen, Anforderungen und auch Ängste vor allzu viel Agilität. Ein professionelles Change- bzw. Stakeholder-Management ist daher für einen erfolgreichen Roll-out wirklich essenziell.

 

Abbildung 3:
Agilität trifft auf unterschiedliche Stakeholder-Interessen

Oft genug kommt es in der Praxis vor, dass agile Projekte mehr oder weniger als „U-Boote“ im Unternehmen mit sehr guten Ergebnissen starten und dass auch die offizielle Pilotierung erfolgreich verläuft. Die Skalierung aber misslingt – vor allem, weil die unterschiedlichen Stakeholder-Interessen beim Roll-out nicht mit der gebotenen Ernsthaftigkeit berücksichtigt wurden. Wir raten unseren Kunden daher grundsätzlich dazu, vor einem solchen Vorhaben objektiv zu prüfen und sich auch selbstkritisch zu hinterfragen, ob die unternehmensspezifischen Rahmenbedingungen und das Umfeld für die Einführung von Agilität heute wirklich reif sind.

Die allein seligmachende Lösung bietet Agilität nämlich nicht. Auch auf der Mitarbeiter-Ebene, die am meisten von der Veränderung profitiert, gibt es immer wieder Personen, die überhaupt kein Interesse daran haben, selbstorganisiert und mit hohen Freiheitsgraden zu arbeiten, sondern die genau gesagt bekommen wollen, was zu tun ist – und ansonsten vor allem um 16.30 Uhr den Heimweg antreten wollen. Hier müssen besondere Change-Aspekte berücksichtigt bzw. neue Aufgabenstellungen gefunden werden.

Das mittlere Management ist in seiner Rolle besonders betroffen, weil es von der zumeist praktizierten „Command-and-Control“-Führung Abschied nehmen und sich selbst zurücknehmen muss. Manche wissen auch nicht so recht, welche Rolle ihnen in der künftigen agil operierenden Organisation zukommt bzw. ob es für sie im Unternehmen überhaupt noch attraktive Rollen geben wird. Hier ist das Top-Management gefordert, klar den Kurs vorzugeben und aufzuzeigen, welche interessanten Aufgaben und Perspektiven es für Führungskräfte der mittleren Ebenen in der künftigen agilen Organisation geben wird.

Das Top-Management muss Agilität zunächst einmal ausreichend gut verstehen, um es nicht gleich als „Voodoo“ abzutun. Ferner ist vom Top-Management eine Führungs- und Vorbild-Funktion im Hinblick auf die anstehende Veränderung einzufordern. Dass der neue Weg auch vom obersten Management mit aller Ernsthaftigkeit verfolgt wird, muss für alle Beteiligte klar erkennbar sein. Fakt ist leider, dass das obere (wie auch das mittlere) Management – auch nach erfolgreicher Pilotierung – oft nicht konsequent genug an der Ausbreitung weiterarbeitet. Ursächlich hierfür ist in vielen Fällen eine unzureichende Transparenz über die tatsächlichen Effekte und Gesamtvorteile, die aus einem größtmöglichen Mehr an Agilität resultieren. Unseren Kunden raten wir daher grundsätzlich dazu, über Kennzahlen nicht nur den vordergründigen Erfolg zu messen – kenntlich gemacht durch die erzielten Effizienzverbesserungen und verkürzten Durchlaufzeiten. Genauso wichtig ist es, den jeweiligen Implementierungsgrad der Methode über sogenannte „Leading Indicators“ zu messen. Denn: Wie die Praxis zeigt, gibt es zwischen dem Implementierungsgrad und den Erfolgskennzahlen eine klare Korrelation.

 

Abbildung 4:
Je höher der Implementierungsgrad umso größer ist der Erfolg agiler Methoden

Die „Leading Indicators“ messen im Prinzip, inwieweit ein Unternehmen die Prinzipien umgesetzt hat, die als Leitlinie für die Ausprägung agiler Methoden im Unternehmen dienen. Sind die Leading Indicators nicht ausreichend erfüllt, das heißt hält man sich nicht an die angedachten Arbeitsweisen, kann sich auch der erwartete Nutzen nicht bzw. nicht in vollem Umfang einstellen. Die Messung des Implementierungsgrades bietet ferner die Chance, mit dem Management von einer fundierten Basis aus eine Roadmap für weitere Verbesserungen zu vereinbaren. Im Beispiel der Abbildung 4 sind einige Schlüsselelemente agiler Methoden bereits vorbildlich umgesetzt (Punkte 6 bis 9). Erkennbar großen Nachholbedarf gibt es hingegen bei der priorisierten Kundensicht (1) und dem durchgängigen Requirements Engineering (2).

Damit der Roll-out übergreifend gelingt und das vorhandene Verbesserungspotenzial bestmöglich ausgeschöpft werden kann, müssen zusammenfassend mehrere Grundvoraussetzungen erfüllt sein:

  • die unternehmensspezifischen Rahmenbedingungen und das Umfeld müssen für den Einsatz agiler Ansätze und Methoden reif bzw. die Erkenntnis vorhanden sein, dass an diesen gearbeitet werden muss
  • eine oder mehrere Pilotierungen müssen die Anwendbarkeit und den Nutzen für die Organisation belegt haben
  • ein individuelles Skalierungsmodell muss erarbeitet und verstanden sein
  • alle Mitarbeiter-/Management-Ebenen müssen ihren persönlichen Nutzen und die zukünftige Rolle verstanden haben
  • es muss ein klares Vorgehenskonzept für den Roll-out vorliegen
  • der Erfolg des Einsatzes agiler Methoden, aber auch deren Implementierungsgrad sind kontinuierlich zu erfassen und zu optimieren
  • der gesamte Prozess muss durch ein professionelles Management der Veränderung begleitet werden. Dies beinhaltet auch, den unterschiedlichen Interessen, Erwartungen und Ängsten auf den einzelnen Hierarchieebenen durch ein spezielles Stakeholder Management zu begegnen

Besonders erfolgreich werden Unternehmen sein, denen es bei ihrem Engagement für Agilität gelingt, die Betroffenen von Beginn an zu Beteiligten zu machen und im anstehenden Veränderungsprozess gleichzeitig Kopf, Herz und Hand der Stakeholder zu adressieren.

TMG INSIGHTS 08: "Antriebskonzepte der Zukunft"

Artikel lesen
Automotive

Mehr