Agile skalieren: Ein praktischer Leitfaden für Enterprise-Teams

Idealerweise:

Direkt zu Beginn der agilen Transformation.

Theoretisch:

Sobald die Komplexität und der Umfang des Projekts groß genug werden, um die Arbeit mehrerer Ressourcen zu erfordern.

Praktisch:

In jeder Phase, in der eine Organisation regelmäßig Folgendes erlebt:

• Mangelnde Zusammenarbeit
• Geschäftsengpässe
• Stagnierende oder rückläufige Umsätze
• Langsamere Lieferzyklen
• Komplexe Prozesse
• Organisatorische Reibungsverluste
• Arbeit in Silos
• Bürokratische Hürden
• System, das von einem Team zum anderen zusammenbricht

Dies sind allesamt aussagekräftige Symptome einer agilen Umsetzung, die skaliert werden muss.

In dieser Phase benötigen Sie eine Bewertung, um herauszufinden, wie gut Ihre Organisation für das Skalieren von Agilität gerüstet ist. Suchen Sie Unterstützung auf Führungsebene, um das Fehlen spezialisierter Einheiten wie Design-Spezialisten, IT-Spezialisten, Sicherheitsspezialisten, Stakeholder-Unterstützung usw. zu bewerten und festzustellen, welche unternehmensweiten Faktoren Sie am Skalieren von Agilität hindern.

• Bottom-up
• Top-down

Bei einem Bottom-up-Ansatz müssen Sie das Skalieren auf Teamebene beginnen und sich dann nach oben zu anderen Teams und zum Management der Organisation vorarbeiten.
Das funktioniert perfekt für Teams, die unabhängig von der Arbeit der anderen sind. Aber wenn die Teams voneinander abhängig sind, müssen Sie Ihre Strategie überdenken.

Der Top-down-Ansatz liegt vor, wenn die agile Transition zuerst von der oberen Führungsebene angenommen wird und dann bis auf die Teamebene durchsickert.
Dies lässt sich besser erreichen, indem Sie einen Berater oder einen Agile Coach engagieren, der Sie beim Übergang zum Skalieren von Agilität anleiten kann.

Bei beiden Ansätzen sieht die resultierende Transition strukturell ungefähr so aus: Es gibt eine Reihe kleiner und multidisziplinärer Teams, die an einem komplexen Problem arbeiten, indem sie es in Teile zerlegen. Die Teams liefern für jedes Element der Teile Lösungen, indem sie zügige Minimum Viable Products und enge Feedback-Schleifen einsetzen. Anschließend arbeiten sie zusammen, um all diese Lösungen zu einem stimmigen Ganzen zu integrieren. Das Erfolgsgeheimnis dieser Zusammenarbeit besteht darin, sicherzustellen, dass nicht der Plan, sondern die Reaktion auf Veränderung der entscheidende Faktor ist. Eine eindeutige Kennzahl zur Messung des Erfolgs des Prozesses ist die Verlagerung des Fokus vom Output (wie etwa Codezeilen oder Anzahl neuer Produkte) hin zu den Ergebnissen (wie etwa Wachstum, Umsatz und Kundenerlebnis).

• Wie lautet Ihre Geschäftsstrategie?
• Wie viele Projekte sind geplant?
• Wie viele Teams werden daran arbeiten?
• Wie hoch ist die Komplexität eines einzelnen Projekts?
• Sind Ihre aktuellen Teams ausreichend ausgestattet und qualifiziert, um an diesen Projekten zu arbeiten?
• Was funktioniert gut? Was muss verbessert werden?
• Unterstützt die aktuelle Arbeitskultur die Veränderung?
• Was wären Ihre KPIs für das Skalieren von Agilität?
• Wie gut kennen Ihre Teams Agilität?
• Werden Ihre Teams in einer agilen Umgebung gut arbeiten können?
• Wie würde eine erfolgreiche Transition aussehen?
• Haben Sie Risiken oder Abhängigkeiten identifiziert, die Ihre Transition beeinträchtigen können?

Scaled Agile Framework (SAFe)

Das Scaled Agile Framework (SAFe) ermöglicht es Unternehmen, ihre organisatorischen Ziele zu erreichen und das qualitativ hochwertigste Produkt in der kürzesten nachhaltigen Zeit zu produzieren. Es ist ein Ansatz, der Scrum auf Enterprise-Ebene skaliert und Ihnen die Freiheit gibt, entsprechend Ihren geschäftlichen Anforderungen zu skalieren, unabhängig von der Größe des Unternehmens, die so groß wie Tausende sein kann.

Abgesehen von den traditionellen Scrum-Rollen gibt es in SAFe neue und definierte Rollen wie den Release Train Engineer und den Solution Engineer. Außerdem kommen Zeremonien und Prozesse wie das PI Planning, die Durchführung des Program Increment, der Agile Release Train, der Solution Train und so weiter hinzu.

Es führt eine Philosophie der dienenden und Lean-Agile-Führung ein und geht über die bloße Implementierung einer Organisationsstruktur hinaus, indem es vielmehr eine neue Denkweise verankert. Erfahren Sie mehr über das Spektrum der Rollen in SAFe im Kendis-Blog.

Disciplined Agile (DA)

Disciplined Agile Delivery (DAD) ist ein einfaches und flexibles Framework, das kontextspezifische Orientierung bietet, die auf Ihre unternehmerischen Anforderungen abgestimmt ist, um qualitativ hochwertige Produkte schneller zu produzieren. Es ist ein hybrides Modell, das aus einer Sammlung der weltweit bewährten Lean-Agile-Methoden wie Scrum, Kanban, XP, Agile Modelling, Unified Process und vielen mehr besteht.

DA befasst sich mit der Projektlieferung von ihrem Beginn bis zur Auslieferung an die Endbenutzer, indem es die Barrieren zwischen der Entwicklung und anderen Teilen der Organisation abbaut, um alles in einer einzigen gemeinsamen Anstrengung zu bündeln. Es koordiniert und richtet die Scrum-Teams mit dem Rest der Organisation und deren Arbeit aus, sodass alles transparent bleibt.

Large Scale Scrum (LeSS)

Large Scaled Scrum, abgekürzt als LeSS, ist eines der führenden Frameworks der agilen Softwareentwicklung. Es ist ein Multi-Team-Scrum-Framework, das auf ein agiles Team von zwölf, hundert oder sogar Tausenden von Personen angewendet werden kann, die alle gemeinsam an einem bestimmten geteilten Produkt arbeiten.

Mit LeSS können Sie große oder kleine Produkte erstellen. Es ist ein einfaches und minimalistisches Framework, bei dem es weniger Durchsetzung von Regeln, Prozessen, Rollen oder Artefakten gibt. Es gibt nur herkömmliche Scrum-Rollen wie den Product Owner, den Scrum Master und das Team.

LeSS ist sehr kundenzentriert, da Teams direkt mit dem Kunden interagieren, während sich der Product Owner darauf konzentriert, die Roadmap, die Prioritäten und die langfristige Vision des Produkts festzulegen. Erfahren Sie mehr über das Spektrum der Rollen in LeSS im Kendis-Blog.

Tribe

Das von Spotify populär gemachte Tribe-Modell hat die Frameworks zum Skalieren von Agilität nachhaltig verändert. Spotify, ein beliebter Musikplayer, wurde 2008 eingeführt und ist inzwischen zu Teams herangewachsen, die über mehrere Zeitzonen verteilt sind. Sie verdanken ihren Erfolg ihren tief verwurzelten agilen Methoden und der Nutzung des Skalierens von Agilität mit ihrer eigenen Note.

Die in dem Framework als “Squads” bezeichneten Teams nutzen KANBAN, Scrum-Sprints, XP oder eine Mischung aus diesen agilen Methoden, um ihre Aufgaben zu erfüllen. Erfahren Sie mehr über das Spektrum der Rollen im Tribe-Modell im Kendis-Blog.

• Befolgen konsistenter Prozesse und Praktiken
• Unterstützung durch Führungskräfte und Stakeholder
• Verwendung gemeinsamer Werkzeuge über die Teams hinweg
• Beratung oder Hilfe durch Agile Coaches
• Solides Fundament an kontextbezogenem agilem Wissen
• Kürzere Time-to-Market
• Flexibleres und reaktionsfähigeres Arbeitsumfeld
• Gegenseitiger Respekt unter Kollegen
• Gesteigerte Gesamtproduktivität
• Dezentralisierte Entscheidungsfindung

Unvollständiges Verständnis des Frameworks

Viele skalierte agile Transformationen sind bereits zum Scheitern verurteilt, bevor sie überhaupt in die Praxis umgesetzt werden. Der Grund ist dreierlei:

• Oft nehmen die Personen, die die Transformation leiten, fälschlicherweise an, dass das Auferlegen eines Werkzeugsets ihre Organisation auf magische Weise transformieren wird. In diesem Fall wird die Begrenzung des Frameworks zur Begrenzung ihres skalierten Agile.
• Nur wenige Organisationsleiter machen sich die Mühe, das Bedarfsprofil ihres Unternehmens zu verstehen, bevor sie ein bestimmtes Skalierungs-Framework übernehmen. Das führt dazu, dass sie bei den feineren Details der Umsetzung schlecht gerüstet sind und so das Vertrauen des Teams verlieren.
• Eine schlecht vorbereitete Führung kann auch bedeuten, dass jemand sich entscheidet zu führen, nachdem er ein Buch durchgelesen oder einen Schnellkurs absolviert hat, ohne jegliches Erfahrungswissen darüber, wie sich das Skalieren von Agilität durch die Ränge einer Organisation entfaltet. Dies führt zu schlecht umgesetzten Prozessen und einer fehlerhaften Interpretation von Prinzipien.

Mangelnde Motivation zur Veränderung

Aus der eigenen Komfortzone herauszutreten, ist immer schwierig, umso mehr im Kontext großer Organisationen. Trägheit ist absolut real. Das bedeutet, dass, sobald eine Organisation sich auf die Veränderung einlässt, das Erste in ihrer Ausrüstung die Motivation sein sollte, sich nicht vom Unbehagen neuer Prozesse und unbekannten Terrains entmutigen zu lassen.

Eine neue Denkweise entwickeln

Eine wesentliche Voraussetzung bei der Anpassung an jedes Modell zum Skalieren von Agilität ist eine Lean-Agile-Denkweise. Es ist nicht nur eine Person, die sie haben muss, sondern sie muss in der DNA der Organisation verankert sein. Führungskräfte müssen das Konzept der dienenden Führung verinnerlichen, bei dem die Prioritäten der Teams an erster Stelle stehen. Teams muss beigebracht werden, wie sie Verantwortung für ihre Arbeit übernehmen, und sie sollten befähigt werden, ihre eigenen Entscheidungen zu treffen.

Kultureller Wandel

In einem traditionellen Führungsstil sind Teams darauf beschränkt, innerhalb ihrer Silos und gemäß einem hierarchischen System zu arbeiten. Sie sind fest darauf verpflichtet, den von der oberen Führungsebene erstellten Plan zu befolgen. Mit skaliertem Agile muss eine neue Arbeitskultur angenommen werden.

Sie beseitigt die Idee einer Top-down-Hierarchie, schafft die Silos ab und verbessert die Transparenz und Zusammenarbeit zwischen Teams und Management. Die Autorität ist nicht länger zentralisiert.

Diese Kultur anzunehmen, braucht Zeit und ist eine mühsame, aber lohnende Aufgabe. Der mentale Wandel hin zur Annahme einer Kultur, in der die Verantwortung gemeinsam getragen wird, erfordert viel Arbeit und ein starkes Bekenntnis zum Anliegen des Skalierens von Agilität.

Ungeeignete Werkzeuge

Das Bauen in Silos ist ein Ausschlusskriterium für Agilität. Organisationen neigen dazu, Werkzeuge zu verwenden, die sich von Abteilung zu Abteilung unterscheiden. Das verursacht eine Diskrepanz.

Die Harmonisierung des organisatorischen Technologie-Stacks ist eine der größten Herausforderungen beim Skalieren von Agilität. Es muss ein Tracking-Werkzeug geben, das für alle zugänglich sein sollte. Es sollte einen transparenten Informationsfluss ermöglichen und Sichtbarkeit und Zusammenarbeit fördern. Dieses Tracking-Werkzeug soll es Ihnen ermöglichen, strategische Pläne, Abhängigkeiten und Risiken zu erstellen. Kendis ist eine solche Lösung zum Skalieren von Agilität, die sich um alle Planungs- und Tracking-Bedürfnisse ihrer Partner kümmert – vom PI Planning und der Verwaltung von Abhängigkeiten bis hin zur Koordination auf Solution-Ebene, indem sichergestellt wird, dass alle ihre Geschäftsprozesse sichtbar sind.

Remote-Teams

In der Welt nach der Pandemie ist das Remote-Skalieren von Agilität kein neuartiges Konzept mehr. Es bringt eigene Herausforderungen mit sich:

Mehrere Standorte
Verteilte Teams
Interkulturelle Kommunikation
Zunehmende Abhängigkeit von Technologie-Enablern Dritter

Dies sind nur einige Beispiele für Herausforderungen, denen man beim Skalieren von Agilität begegnet. Genau wie bei den Herausforderungen gibt es auch eine Handvoll Mythen rund um das Skalieren von Agilität. Keine dieser Herausforderungen und Mythen ist unmöglich zu bewältigen, sie können jedoch eine harte Nuss sein, wenn Ihre Organisation nicht vollständig darauf vorbereitet ist, mit ihnen umzugehen.

(Müssen Sie diese Herausforderungen mit Ihrem Team teilen? Nutzen Sie unseren eigens dafür erstellten Blogbeitrag zu diesem Thema.)