Über unsMediaKontaktImpressum
Alexander Birke 15. September 2020

Business Agility: Warum es nicht mehr genügt, nur "agil" zu sein

Obwohl "Agil" und "Agilität" seit mehr als 15 Jahren als Begriffe in Unternehmen immer prominenter geworden sind, tun wir uns seit jeher mit einer kurzen und verständlichen Definition schwer. In den letzten Jahren scheint aber "Agilität" als alleinstehender Begriff aus der Mode gekommen zu sein. Neue Trends wie "Enterprise Agility" – zumeist jetzt als "Business Agility" bezeichnet – sind in aller Munde. Reicht es jetzt also für Unternehmen nicht mehr, wenn man nur noch nach dem richtigen Maß an "Agilität" strebt? Und was ist dann diese "Business Agility"? Ist das nur ein Hype oder steckt dahinter ein tatsächlicher Nutzen für Unternehmen?

Um den Unterschied einordnen und den neuen Begriff definieren zu können, machen wir einen kurzen Abstecher zu den Wurzeln von "Agilität". Schon mal vorweg: das Ergebnis wird etwas überraschend sein. Im Weiteren geben wir einen für die Praxis wichtigen Überblick über bekannte und hilfreiche Frameworks bzw. Modelle zu Business Agility.

Zurück zu den Wurzeln: Was ist eigentlich Agilität?

Die Frage führt mich zurück an meine persönlichen Anfänge mit agilen Methoden. Damals diskutierte ich mit einem erfahrenen Coach, wie wir am einfachsten die agile Reife eines Projekts ermitteln könnten. Er hatte eine erstaunlich einfache Antwort: Wir schauen uns nur an, ob wir dort Feedbackschleifen finden. Damit waren regelmäßige Überprüfungen gemeint, verbunden mit einer darauffolgenden Anpassung von Faktoren basierend auf den neu erlangten Erkenntnissen. Finden wir diese Feedbackschleifen aber nicht, sind diese Projekte auch nicht agil!

Das ist nun ca. 12 Jahre her und klingt auf den ersten Blick fast zu simpel, um wahr zu sein, oder? Meine These ist, dass die Hälfte der heutigen agilen Projekte diesem Lackmustest nicht standhalten würde: Nicht alle Feedbackschleifen werden genutzt, geschweige denn, dass in ausreichendem Maße Reaktionen auf die erlangten Erkenntnisse erfolgen. Der Optimalfall wäre sogar, dass Teams mit vorab formulierten Hypothesen arbeiten.

Eine sicher klarere Definition von Agilität liefert Jim Highsmith, einer der Autoren des Agilen Manifests, in seinem Buch "Agile Software Development Ecosystems" von 2002 [1]: "Agility is the ability to both create and respond to change in order to profit in a turbulent business environment."

Was genau bedeuten die drei Kernbestandteile dieser Definition und sind sie heute, fast 20 Jahre später, überhaupt noch relevant?

Der erste Teil "ability to […] respond to change" ist wenig überraschend. Er erinnert uns an die Wertepaare des Agilen Manifests [2]. Die Beschreibung, dass es sich um eine "Fähigkeit" (eng. ability) handelt, ist dabei sehr wichtig. Agile Organisationsformen sind nicht per se reaktiv, sondern verfügen über die Fähigkeit, es – wenn notwendig – sein zu können.

Jim Highsmith spricht weiter von "profit" und meint damit den resultierenden Nutzen der Anwendung von "Agilität". Gerade dieser Aspekt scheint über viele Jahre hinweg eher in den Hintergrund geraten und Agilität zum Selbstzweck geworden zu sein. Bevor wir "agile Methoden" einführen, muss bewusst und differenziert diskutiert werden, wo, in welcher Form als auch in welchem Ausmaß sie etabliert werden sollen. Agilität muss einem höheren Ziel bzw. "Nutzen" (eng. profit) dienen und ist hierbei idealerweise an konkrete unternehmerische Herausforderungen oder Geschäftsziele gekoppelt. Mögliche Ziele sind eine gesteigerte Liefertreue oder Innovationskraft.

Zuletzt macht Highsmith klar, wann bzw. in welchem Umfeld er "Agilität" für angemessen hält: "in a turbulent business environment". Um die "Turbulenzen" des Marktes, der dort tätigen Firmen und deren Produkte der letzten 15 Jahre zu rekapitulieren, schauen wir uns exemplarisch 3 Typen von – wie wir sie heute nennen würden – disruptiven Ereignissen an:

  1. Seit langem bestehende Produktarten werden abgelöst und der Wechsel der Produktgenerationen setzt Firmen und ganze Branchen unter Druck. Berühmte Beispiele sind hier die Ereignisse um Blockbuster bzw. Netflix, Kodak oder Nokia.
  2. Bestehende Produkte werden verbessert, z. B. werden sie schneller, einfacher, günstiger: sei es die nur ein paar Dutzend Mitarbeiter umfassende Firma hinter WhatsApp, die heute die Kommunikation zwischen Milliarden von Menschen gestaltet oder auch das Banking der Zukunft durch N26 oder viele andere FinTechs.
  3. Neue plattform-basierte Geschäftsmodelle sind echte "Game-Changer" wie z. B. Uber, Airbnb usw.

Das Konzept der Agilität ist also doch schon recht umfassend. Warum also nun auch noch "Business Agility"?

Die Entstehung von "Business Agility"

Der Begriff der "Business Agility" taucht interessanterweise in der Wirtschaftsliteratur weit vor der Geburtsstunde von Agilität, wie wir sie seit dem Agilen Manifest kennen, auf [3]. Es existieren verschiedene Strömungen, die zum Begriff der "Business Agility" basierend auf unserem heutigen Agilitätsbegriff, geführt haben. Auch wenn sich alle aus verschiedenen Richtungen ergaben, so ist meine Beobachtung, dass sie wichtige Bestandteile, die bereits in der Aussage von Highsmith enthalten waren, betonen bzw. den Stand der Entwicklung hervorheben wollen.

Eine der ersten Quellen zu "Business Agility", im Jahr 2016 auf DZone erschienen, spricht von den "3 Waves of Agility" [4]. Mein Kollege Charlie Rudd betrachtet dabei Agilität als Konzept, welches sich in seiner Anwendbarkeit evolutionär weiterentwickelt hat. Die zugrundeliegenden Prinzipien sind seit den frühen 2000er u. a. durch das Agile Manifest gegeben, aber die Form, wie sie auf verschiedenen Ebenen in der Organisation praktisch und effektiv anwendbar sind, ergaben sich nach und nach in 3 Wellen.

Die erste Welle fokussiert Agilität vor allem auf die Teamebene. Es geht darum, Teams und die interne Zusammenarbeit durch smarte Prozesse und Methoden aber vor allem auch mehr menschen- und individuengerecht zu gestalten. Mit der zweiten Welle 2007 und Ken Schwabers "The Enterprise and Scrum" [5] begann die Welle der Skalierung von Agilität auf weitere Teams. Damals noch unbekannt und in der Early-Adopter-Phase ist daraus auch das, was wir heute unter dem ScaledAgileFramework (SAFe) kennen, entstanden [6]. Die Phase ist charakterisiert von der Suche nach Prozessen und Methoden, die es ermöglichen, mehrere an einem Ziel/Produkt arbeitende Teams unter Berücksichtigung der agilen Prinzipien zu koordinieren und zu synchronisieren. Erst die dritte Welle adressiert einen ganzheitlichen Ansatz. Dieser bezieht jenseits einer agilen "Skalierungsebene" über mehrere Teams hinweg auch unterstützende Einheiten wie eine Rechtsabteilung, Marketing, HR usw. ein. Diese dritte Welle bezeichnet Charlie als "Business Agility". Damit konzentriert sich die 3. Welle jenseits des agilen Managements von Teams, Projekten oder Einheiten auf die ganze Organisation. Das Konzept möchte alle an einem Kundenanliegen bzw. Wertstrom des Unternehmens beteiligten Teams bzw. Einheiten integrieren und unter Nutzung agiler Prinzipien und Methoden miteinander optimal verknüpfen. Werke wie Jurgen Appellos "Management 3.0" [7] oder Steve Dennings "Radical Management" [8] von 2010 sind frühe Elemente dieser Welle, da sie jenseits der Team- und Projektstrukturen auf den gerade auch auf höheren Ebenen einer Organisation relevanten Aspekt von agilem Management eingehen. Ein weiterer Aspekt der dritten Welle ist der Fokus auf den Einsatz von Agilität auf der Suche nach erfolgreichen Produkten und Geschäftsmodellen. Hier finden wir mit Eric Ries "Lean Startup" im Jahre 2011 einen der ersten und immer noch sehr bekannten Impulse [9].

Die Wellen scheinen sich mit der schnellen Abfolge vom Jahr 2007 auf das Jahr 2010 sehr schnell und kurz hintereinander zu entwickeln. Die Entstehung einer neuen Welle signalisiert jedoch nicht das Ende der vorhergehenden Welle. Sie überlagern sich. Auch soll der Start der "Business Agility"-Welle im Jahr 2010 nicht darüber hinwegtäuschen, dass wir heute noch weit von einem Verständnis, wie hier vorzugehen ist, entfernt sind – geschweige denn haufenweise Beispiele aus großen Unternehmen vorliegen haben.

Wie Business Agility den Unterschied macht

Die Forderung neben agilen Entwicklungsteams nun Management und sämtliche Unterstützungsfunktionen zu agilisieren stellt Unternehmen vor große Herausforderungen. Eine Begründung für die Notwendigkeit liefert eine Aussage von Evan Leybourn, die er mit Blick auf Unternehmen als komplexe Systeme (vgl. Complex Adaptive Systems) macht [10]: "An organisation can only be as agile as it’s least agile division!" Evan meint damit, dass ein Wertstrom einer Organisation nur so agil sein kann wie seine in diesem Wertstrom beteiligte am wenigsten agile Einheit [11].

Ein Extrembeispiel für diese Problematik finden wir in folgendem Beispiel eines Ende-zu-Ende-Ablaufs in einer Organisation dargestellt (s. Abb. 2). Es zeigt anschaulich die typische Umsetzung von Agilität in der zweiten Welle. Wir sehen einen Prozess, schematisch als Kanban Board dargestellt, der sich über einen Pool von neuen Ideen links bis hin zur Auslieferung einer passenden Umsetzung rechts erstreckt [12].

In der Spalte "DEVELOP" könnten perfekt organisierte, in der Entwicklungsabteilung aufgehängte agile Teams schnell und qualitativ hochwertige Software in zweiwöchigen Sprints produzieren. Klingt erstmal hervorragend! Jedoch haben zweiwöchige Sprints in der IT für eine große Organisation kaum Relevanz, wenn für die Realisierung einer Funktionalität vor und nach einem Sprint mehrere Monate oder sogar Jahre benötigt werden. Die Entfernung vom Kunden, die langen Entscheidungswege und der Informationsverlust durch zahlreiche Übergaben machen klar, dass man mit dieser "zu isolierten" Form von Agilität die Vorteilsversprechen noch nicht realisieren kann. Nach der "Lean-Denkweise" spricht man von einer lokalen Suboptimierung.

Sicher kommt eine hohe Agilität in der Softwareentwicklung bereits mit Vorteilen wie besserer Qualität und Usability (durch frühe Tests und Korrekturen) sowie besserer Vorhersagbarkeit der Liefergeschwindigkeit. In Summe zeigt das Beispiel stellvertretend auf, auf welche Art von Teams, nämlich die in der IT, sich Agilität vor allem in der ersten und zweiten Welle (und oftmals heute immer noch) konzentriert. Aber das ist heute nicht mehr genug. Damit wird auch klar, warum die dritte Welle und der Begriff "Business Agility" seine Berechtigung bzw. sogar Notwendigkeit hat.

Auf dem Weg zu einer Definition

Das vorangegangene Beispiel zeigt, dass "Business Agility" zum einen den organisatorischen Fokus klar jenseits der IT über weitere an der Wertschöpfung beteiligte Organisationeinheiten setzt.

Eine gute Definition stammt von meinem Kollegen Philipp von Bentivegni [8]: "Business Agility" steht für eine neue Unternehmenskultur, die Agilität auf allen Ebenen eines Unternehmens fördert und diese damit möglichst reibungsfrei verbindet. Agile "Inseln" und damit lokale Optimierungen wie schlimmstenfalls einzelne nicht abgestimmte agile Teams oder auch einzelne agil aufgestellte Produkte sind daher nur kleine Bausteine auf dem Weg zur unternehmensweiten Agilität."

Business Agility betont zudem die Perspektive des Geschäfts(-modells) bei der Anwendung von agilem Handeln und Denken einzunehmen. Das zeigt sich in der dritten Welle durch Eric Ries "Lean Startup". Hiermit wären wir dann wieder bei der Idee der Ausrichtung des ganzen Unternehmens im Sinne des "profit"-Gedankens von Highsmith: Agilität, um Vorteile für das (Weiter-)Bestehen des Unternehmens zu sichern.

Business-Agilität und Agilität – auf den Punkt gebracht!

Eine Organisation hat Business-Agilität realisiert, wenn es die Fähigkeiten besitzt, auf Änderungen von innen und außen schnell und effektiv reagieren zu können, um ihren Zweck (eng. purpose) zu realisieren bzw. einen Wettbewerbsvorteil aufzubauen, zu erhalten oder zu vergrößern.

Der Begriff der "Business Agility" baut damit auf den Inhalten von Agilität bzw. auf Jim Highsmiths Definition auf. Der Unterschied liegt in der Betonung von 3 zusätzlichen Faktoren und damit einem geschärften Fokus:

  1. Agilität existiert über die komplette Organisation hinweg: Ende-zu-Ende, sicher aber jenseits der IT, nach heutigem Kenntnisstand in Wertströmen organisiert mit angebundenen Unterstützungsfunktionen wie Recht, Marketing und HR.
  2. Management bzw. Leadership über alle Hierarchieebenen hinweg leben Agilität vor und fördern sie.
  3. Der Einsatz von Agilität dient dem Ziel des Erreichens eines klaren Geschäftsmehrwerts, um im extremsten Falle das Überleben der Organisation zu ermöglichen.

Gerade der letzte Punkt soll uns Agilisten erinnern, dass agile Methoden und Tools in dem Umfang genutzt werden sollen, wie es in dem Kontext der konkreten Organisation hilfreich ist. Wir wollen Vorteil fürs Business schaffen, das ist für die ganze Firma und nicht nur ein Team oder eine Abteilung.

Weitere Definitionen von Business Agility

Man findet viele Definitionen von Business Agility, die sich im Detailwortlaut unterscheiden, aber in den Inhalten immer wieder auf die gleichen Faktoren abzielen – übrigens sehr ähnliche wie in Jim Highsmith' Aussage von 2002: Reaktionsfähig, am Markt bzw. am Kunden orientiert sein und (Wettbewerbs-)Vorteile für Unternehmen bzw. Kunden erzielen.

  • Wikipedia: In a business context, agility is the ability of an organization to rapidly adapt to market and environmental changes in productive and cost-effective ways [13].
  • Business Agility Institute: Business agility is the capacity and willingness of an organization to adapt to, create, and leverage change for their customer’s benefit [14].
  • McKinsey: Agile organizations can quickly redirect their people and priorities toward value-creating opportunities [15].
  • Scrum Alliance: Business agility is the ability of an organization to sense changes internally or externally and respond accordingly in order to deliver value to its customers [16].
  • Agile Business Consortium: Business agility is the ability of an organisation to:
    • Adapt quickly to market changes - internally and externally,
    • Respond rapidly and flexibly to customer demands,
    • Adapt and lead change in a productive and cost-effective way without compromising quality,
    • Continuously be at a competitive advantage [17].
  • SolutionsIQ: Business agility is the ability of a business to realize and sustain its full potential both in terms of its profits and its people, regardless of internal or external environment changes [18].
  • ScaledAgileFramework / SAFe von SAI: Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative business solutions [19].
  • Agility Health: Business agility is the ability to adapt and change, learn and pivot, deliver at speed, and thrive in a competitive market [20].

Ressourcen zu Business Agility

Mittlerweile haben sich diverse Modelle und Frameworks rund um Business Agility entwickelt. Zum Teil sind auch einige – meist ältere – Modelle rund um Enterprise Agility noch relevant. Im Folgenden stellen wir eine Auswahl an bekannteren Modellen, die für unterschiedliche Zwecke und in unterschiedlicher Tiefe definiert sind. Sie sind größtenteils frei verfügbar bzw. zusätzlich über Schulungen erlernbar.

Interessanterweise hängen die drei im Folgenden im Detail beschriebenen Modelle, die nach meiner Ansicht aktuell den meisten Mehrwert bringen, eng miteinander zusammen. Die frühe Bewegung um Charlie Rudd und seiner Firma SolutionsIQ führte mit weiteren Vorreiterfirmen u. a. auch AgilityHealth zur Gründung des Business Agility Institutes. AgilityHealth ist Urheber des Enterprise Business Agility Models. Unter Leitung des Business Agility Institutes und dort Evan Leybourn wurde das "Domänenmodell für Business Agility" definiert. Die SAFe Fellows von SolutionsIQ und die Zusammenarbeit zwischen AgilityHealth und SAFe im Rahmen der Reifegradmessung bilden eine weitere Verbindung. Das dritte näher betrachtete Modell wird das SAFe-Modell zu Business Agility sein. Im Text folgen daher immer wieder Anmerkungen zu Ähnlichkeiten oder Unterschieden, Verbindungen und Überschneidungen .

Das Business Agility Institute und das Domänenmodell für Business Agility

Ein anbieter-agnostisches Modell und eine Webseite bzw. Community mit vielen Ressourcen stellt das Business Agility Institut bereit [21]. Zum einen bietet es eine Plattform für Interessierte und Anwender, welche durch weltweit durchgeführte Konferenzen und Meetups auch einen persönlichen Austausch ermöglicht. Weiterhin wird jährlich der "Business Agility Report – State of Business Agility" erhoben und veröffentlicht [22].

Das dahinterliegende Modell nutzt 12 sogenannte "Domains of Business Agility", welche in vier Dimensionen untergliedert sind: Leadership, Individuals und Operations (im Außenbereich) und Relationship (im Zentrum).

Den Kunden im Zentrum umgeben die 12 Domains, unterteilt in die 4 Dimensionen. Das Modell betont, dass die 12 Domänen miteinander verbunden und gleich wichtig sind. Die Urheber bezeichnen dies als Checkliste, da sie alle Faktoren als relevant für Business Agility bzw. für eine Agile Organisation ansehen. Die 12 Domains im Einzelnen sind:

– Relationship Domain

  • Board: Agiles Denken und Handeln muss von der obersten Ebene her ("Board of Directors") verstanden und vorgelebt werden.
  • Workforce: Jeder im Unternehmen muss wissen, was Agilität bedeutet und sich entsprechend der agilen Kultur verhalten. Damit in Summe ein Vorteil entsteht, ist eine gemeinsame Ausrichtung, Empowerment und Leidenschaft notwendig.
  • Partners: Realisierung einer partnerschaftlichen Zusammenarbeit mit anderen Firmen auf Augenhöhe. Die Dimension ähnelt sehr der Idee hinter dem agilen Wertepaar "Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlung", welche auch dem "lean"-Umgang von Toyota mit seinen Zulieferern entspricht.

– Individual Domain

  • Growth Mindset: Etablieren einer Lern- und "Fehlerkultur", d. h. toleranter und konstruktiver Umgang mit Fehlern und kontinuierliches & lebenslanges Lernen.
  • Craft Excellence: Etablieren von Fähigkeiten, die Exzellenz und hochqualitatives Arbeiten mit Fokus auf das Wesentliche ermöglichen.
  • Ownership & Accountability: Übernehmen von Verantwortung eines jeden Einzelnen durch vorher übertragene Entscheidungserlaubnis – auch in Situationen hoher Unsicherheit.

– Leadership Domain

  • People Management: Managementebene soll mit agilem Mindset agieren, Entscheidungen delegieren, sowie Personen mit agilem Mindset einstellen und Menschen-zentrierte Führungskultur leben.
  • One Team: Abbau einer "Wir-und-Ihr-Haltung" hin zu gemeinsamen, übergreifenden Zielen, über Teams und Abteilungen hinweg.
  • Strategic Agility: Kommunikation der Strategie über eine zentrale Vision, die Kreativität lässt, das Ziel auf innovativen und selbst gewählten Wegen zu erreichen.

– Operation Domains

  • Structural Agility: Grundsätzlich sind Teams solange wie möglich stabil zu halten. Strukturen sind aber flexibel und können unbürokratisch geändert werden, so dass Teams optimal Mehrwert für das Unternehmen realisieren können.
  • Process Agility: Schlanke, bei Bedarf adaptive Prozesse, die am Kunden orientiert und ständig verbessert werden.
  • Enterprise Agility: Die Governance-Strukturen auf höchster Ebene, z. B. Portfolio-Management muss Einheiten und Teams im Unternehmen Freiheiten geben, auf einfache, schnelle und unbürokratische Weise eigene Ideen realisieren zu können.

Beurteilung

  • Das Modell ist übersichtlich, einfach zu verstehen und gut dokumentiert. Es eignet sich daher für einen ersten Einstieg und gleichzeitig fundierten Überblick.
  • Es ist kundenzentriert, greift viele bekannte Konzepte aus dem agilen Manifest oder von Lean auf und macht einen vollständigen und doch überschneidungsfreien Eindruck, ohne zu überfordern.
  • Per Webseite und PDF ist es in mehreren Detailstufen frei zugänglich, sogar inklusive Druckvorlagen [23]. Auf den Detailseiten zu den Domains ist auch eine vierstufig beschriebene Skala zur Reifegrad-Selbsteinschätzung enthalten.
  • Der Detaillevel wird dem Anspruch als Checkliste gerecht. Das bringt den Nachteil mit sich, dass, wer mehr will – z. B. Beispiele oder gar ein Framework für ein dazu passendes agiles Organisationsmodell – sich an anderer Stelle behelfen muss.

Business Agility Core Competencys aus SAFe

SAFe nutzt seitdem sich die Version 5.0 auf dem Markt befindet, erstmals den Begriff "Business Agility". Business Agility definiert sich dort über die sieben Core Competencys und die Kundenzentrierung (Customer Centricity) [19]. Sehr prominent ist auch der Hinweis "Measure & Grow" auf die Notwendigkeit der kontinuierlichen Arbeit an der Organisation, um Business Agility via Standortbestimmung und konkreter Verbesserungsaktionen zu erreichen.

Wer SAFe aus früheren Versionen kennt, wird beim Blick in die Elemente, genannt "Dimensions", hinter den einzelnen Core Competencys viele bekannte Inhalte wiedererkennen. Updates erhielten Agile Product Delivery, Lean-Agile Leadership, vor allem aber Continuous Learning Culture.

Da die Core Competencys sehr einfach und übersichtlich auf der Webseite von SAFe beschrieben sind, hier ein kurzer Überblick [19]:

  • Lean-Agile Leadership als die zentrale Basis des SAFe Frameworks betont das notwendige Growth Mindset basierend auf einem Lean-Agile Mindset und Prinzipien, Führung durch Vorbild über Agile Leaders, sowie Bausteine für Führung im Wandel u. a. basierend auf Kotters "Leading Change" [24].
  • Team and Technical Agility beschreibt sowohl die Struktur agiler Teams als auch wie eine skalierte Struktur aus agilen Teams aussehen soll inklusive dazugehöriger Prinzipien zur Qualitätssicherung.
  • Agile Product Delivery beschreibt einen Satz von Methoden, um die wahren Bedürfnisse des Kunden zu verstehen, diese hypothesenbasiert und iterativ zu realisieren und unter Nutzung von DevOps- und Continuous-Delivery-Methoden zu liefern.
  • Enterprise Solution Delivery ergänzt Methoden für die Koordination und den Bau sehr großer, komplexer Systeme, u. a. auch jenseits reiner Software-Lösungen.
  • Lean Portfolio Management umfasst den Dreiklang aus Strategie & Investment Funding, der Durchführung von Agile-Portfolio-Prozessen bis hin zum Nachhalten der Resultate mit einer Lean Governance.
  • Organisational Agility enthält zum einen die Basis agilen und Lean-Handelns in Form von Werten und Prinzipien. Ein weiteres Element sind die Lean Business Operations, die auf Value Stream Mapping und Elementen wie den sieben Verschwendungen in Lean basieren. Als drittes Element ist die Strategische Agilität enthalten, über die der enge Kontakt zum Marktgeschehen und dem Wettbewerb sichergestellt werden soll.
  • Continuous Learning und Culture umfasst kulturelle Elemente und das Mindset für eine Lernende Organisation, ein Relentless Improvement und eine Innovation Culture.

Beurteilung

  • Hinter den Core Competencys versteckt sich letztendlich SAFe mit allen seinen Inhalten. Das bringt den Vorteil vieler Informationen mit sich. Es bietet für fast alle Bereiche einer agilen Organisation "Initiallösungen". Dafür bedient es sich größtenteils aus diversen anderen bekannten Methoden und Frameworks. Auch wenn auf den Webseiten einiges an Beschreibung zu finden ist, so gibt es zu vielen dort nur kurz beschriebenen Methoden ganze Bücher. Durch die Masse und Detailtiefe ist es damit trotzdem komplex und für Einsteiger schwer verdaulich.
  • Positiv sind die verschiedenen Zugangskanäle, d. h. vor allem die freien Informationen auf der Webseite sowie diverse Schulungs- und Zertifizierungsformate.
  • Positiv ist, dass für Standortbestimmungen jenseits der Nutzung der kommerziellen und ausgefeilten Agility Health Radars, diese auch über eine Version in Excel vorliegen. Sie sind in 2 Detailstufen über ein Business Agility Assessment [25] oder als Detail-Assessments zu jedem der Core Competencys [26] auf den Webseiten erhältlich.
  • Über die ebenfalls frei zugängliche SAFe Collaborate Plattform wird ein "Growth Forum" für jede Core Competency angeboten [27]. Die Plattform listet in drei Erfahrungsstufen (Core, Intermediate und Advanced) eine Lernempfehlung für frei zugängliche Ressourcen und Hinweise auf SAFe Kurse auf.

Enterprise Business Agility (EBA) Model

Das EBA-Modell unterstützt im Vergleich zu den anderen Modellen die Definition eines Transformationspfads von einem Status Quo hin zu Business Agility. Es baut dabei auf sieben Pillars als Grundlage auf.

Das Modell ist als Übersicht mit Boxen in einer einfachen Matrixanordnung dargestellt. Die oberste Reihe zeigt hierbei sechs der sieben Pillars. Darunter befinden sich je drei vertiefende Subelemente, als Capabilitys bezeichnet, zu jedem Pillar. Der siebte Pillar "Technology Agility" dient wiederum als Fundament für alle anderen und wird daher im unteren Bereich der Visualisierung querschnittlich angesiedelt. Darunter – aber wie bei SAFe zentral im Modell ersichtlich – findet sich auch hier der Hinweis auf die Verwendung von Metriken und Messgrößen, was sich hier u. a. aus dem primären Geschäftsmodell von Agility Health, der Firma hinter EBA, ableitet.

Es folgt ein Überblick über die sieben Pillars. Durch die oftmals strukturelle Ähnlichkeit zu SAFe wird auch – wenn relevant – direkt auf die dazu passende SAFe Core Competency verwiesen.

Die sieben Pillars des EBA-Models [28]:

  1. In Customer Seat at the Table finden sich alle Methoden, die helfen, das richtige Produkt für das anvisierte Zielpublikum zu bauen. Das startet beim Verstehen der wahren Kundenbedürfnisse über die Validierung von Hypothesen bis hin zu Methoden zur Einbeziehung der Kunden in diesen Prozess. Weitestgehend entspricht das der SAFe Core Competency Agile Product Delivery.
  2. In Lean Portfolio Management findet die Koordination des Demands statt, was einen klaren Prozess von den ersten Ideen, über eine outcome-basierte Bewertung bis zum Funding und der Ergebnisnachverfolgung umfasst. Das ist 1:1 das, was SAFe unter Lean Portfolio Management versteht.
  3. In Org Design & Structure werden agile Strukturen, agile Teams und Rollen definiert. Mit Enablement Teams wird ein besonderer Fokus auf die Definition von Teams gelegt, die die primär wertschöpfenden agilen Teams bei ihrer Arbeit unterstützen. Das können Zulieferteams, Komponententeams oder – in SAFe-Terminologie – System Teams sein [29].
  4. Agile Framework & Mindset zielt auf die bekannten Grundlagen Scrum, Kanban und bei Skalierung auch auf Elemente aus SAFe ab. Agile for Business Teams enthält Besonderheiten eines fachlichen arbeitenden agilen Teams. Die dazu passende Core Competency ist Team and Technical Agility.
  5. Leadership & Culture enthält Grundlagen für Agiles Mindset und Leadership, legt aber besonderen Fokus auf den Übergang von traditionellen Managern hin zu neuen Verhaltensweisen im agilen Kontext. Weitestgehend entspricht das den Inhalten aus dem Lean-Agile Leadership, aber auch aus Continuous Learning Culture von SAFe.
  6. Make it stick/sustain beschäftigt sich mit dem effektiven Aufbau eines Change-Teams, sowie der Erfolgsmessung und passenden Metriken für den Change. Ein besonderes Augenmerk wird auf das Finden und Entwickeln agiler Talente gelegt, was eine Veränderung der heutigen HR-Kompetenzen bedarf.
  7. In Technology Agility wird der Prozess von der Architekturvision über die entsprechenden Qualitäts-Methoden und Architekturprinzipien zur Umsetzung bis hin zu modernen Methoden des Bauens und der Auslieferung von Software zusammengefasst. Diese Elemente finden sich verteilt über Core Competencys Agile Product Development und Team and Technical Agility.
  8. Enterprise Agility Metrics umfasst ein Set von Metriken und die Erhebung von dazugehörigen Kennzahlen.

Beurteilung

  • Das Modell hat seine Stärken in der Unterstützung der Erstellung und Durchführung eines Transformationsvorgehens zur initialen Einführung oder Verbesserung der Business Agility. Es hat weniger das Ziel, ein vollständiges Framework, welches eine agile Organisation beschreibt, zu bieten.
  • Überschneidungen zu SAFe sind damit weniger inhaltlicher Natur, sondern liegen mehr auf der strukturellen Ebene. Das Modell zielt stärker auf das Transformationsvorgehen und die Reifegradmessung ab, braucht aber eine Art "Zielmodell" im Hintergrund. Indem es EBA-Konzepte sehr ähnlich wie in SAFe darstellt, spart es sich diese selbst zu definieren. Erfahrung mit SAFe ist daher eine gute Voraussetzung, um das Modell effektiv nutzen zu können. In ausgewählten Bereichen ergänzt es SAFe sogar um dort nicht vorhandene Inhalte, die ich persönlich für wertvolle Ergänzungen halte.
  • Zu den sieben Pillars findet sich online je eine Seite an Informationen inklusive Videoüberblick. Die Inhalte zu den Sub-Elementen sind erst nach Zertifizierung zugreifbar. Man kann sich gut mit den SAFe Core Competencys behelfen. Der Weg, um das Transformations-Framework vollständig zu verstehen oder anzuwenden, führt aber über die zweitägige Schulung inkl. Zertifizierung zum Modell.
  • Hinterlegt mit unzähligen Agility Health Radars bietet EBA ein – wenn auch kostenpflichtiges so doch sehr mächtiges – Werkzeug zur Selbsteinschätzung, Reflektion und schrittweisen Verbesserung. Je ein Agility Health Radar pro Capability ermöglicht die Bestimmung der Reife in dieser und hilft damit Unternehmen zu verstehen, wo sie sich auf ihrer Reise zu Business-Agilität befinden.

Ressourcen im Überblick

Die Kurzbeschreibungen der einzelnen Frameworks zeigen, dass alle drei Parteien miteinander reden, ja sogar Elemente gemeinsam entwickeln. Trotz der Ähnlichkeit an vielen Stellen sind die Endprodukte recht unterschiedlich. Was wem im Einzelfall weiterhilft, ist abhängig vom eigenen Wissensstand und der zu bearbeitenden Fragestellung:

  • Wer einen Detaillevel sucht, auf dem er frei zugängliche und detaillierte Informationen zu einem Organisationsmodell findet, der ist mit dem Angebot von SAFe gut bedient – muss aber auch mit der Komplexität zurechtkommen.
  • Wer einen Weg sucht, seine Business-Agility-Einführung schrittweise zu planen und die Standortbestimmung durch Assessments und Reifegrade für essenziell erachtet, der wird sich im EBA-Model gut wiederfinden. Nachteil ist in jedem Fall, dass hier eine Investition in die Schulung bzw. die Agility Health Radars notwendig ist, um an die notwendigen Detailinformationen zu kommen bzw. das Modell in der Praxis anzuwenden.
  • Wer ein leicht verdauliches und übersichtliches Modell für Business Agility sucht, welches einen schnellen aber trotzdem für Business Agility umfassenden Überblick bietet, der kann auf die "Domains for Business Agility" zurückgreifen. Auch wenn es stärker auf Prinzipien als konkrete Praktiken fokussiert, so ist hier ein Absprung zu SAFe ebenfalls leicht möglich. Und auch auf ein einfaches Reifegradmodell muss man nicht verzichten.

Grundsätzlich eignen sich auch Enterprise-Agility-Modelle, sowie Skalierungsmodelle wie LeSS, Scrum@Scale [30] oder XSCALE [31] für den Start einer Business Agility Journey. Sie besitzen aber meist nicht die Breite in allen für Business Agility wichtigen Elementen (z. B. Agile HR) oder erwähnen Business-Agility-Konzepte nur sehr oberflächlich (vgl. Support-Funktionen im LeSS Framework [32]).

Weitere weniger ausführliche oder umfangreiche Modelle für Business Agility sind folgende vier:

  1. McKinsey entwickelte im März 2020 zusammen mit Scrum.org "Enterprise Agility" [33]. Im Whitepaper ist ein einfaches Transformationsvorgehen und Org-Modell inklusive eines Assessments definiert.
  2. SolutionsIQ bietet mit dem Business-Agility-Modell ein visuell einfaches Modell, das sich darauf fokussiert, die für Business Agility zu erreichenden organisationalen Fähigkeiten zu definieren [34]. Um das Modell herum existieren viele Ressourcen wie Blogs, Podcasts etc. [35].
  3. Das Framework BusinessAgility.works bezeichnet sich selbst als High-level-Framework [36]. Es ähnelt einem auf Prinzipien basierenden Designvorgehen für agile Organisationen. Sehr konzeptionell gehalten, liefert es durchaus interessante Impulse und ist gut beschrieben.
  4. Das Agile Business Consortium zeigt auf seiner Webseite lediglich ein recht simples Modell von Business Agility, bietet dort aber keine weiterführenden Informationen [37].

Abschließend möchte ich darauf hinweisen, dass natürlich auch viele Thought Leader "Business Agility" in ihr Angebot aufnehmen oder neue Modelle dazu ausarbeiten. Klaus Leopold geht in seinem Buch "Agilität neu denken: Warum agile Teams nichts mit Business Agilität zu tun haben" viel auf die Probleme einer Einführung von Agilität ein, die eben nicht die von Agilität versprochenen Vorteile realisierte [38]. Auch bei Jurgen Appelo findet sich das Thema, wenn auch etwas versteckt. Das zugrundeliegende Buch heißt (nur) "Startup, Scaleup, Screwup" [39]. Der Workshop dazu läuft unter "Shiftup Business Agility & Innovation Leader Workshop" und auch auf der Webseite Shiftup wird als zentraler Fokus "Continuous Innovation & Business Agility" aufgeführt [40]. Im Buch und den Workshops dazu geht es um Business-Modelle, deren Validierung und die daraus resultierenden verschiedenen Entwicklungsstufen, deren Erfolgsmessung, sowie im weiteren um die Skalierung.

Business Agility – ein Fazit

Was bedeutet "Business-Agilität" für Coaches

Unter versierten Agile Coaches bräuchte es, meiner Meinung nach, den Begriff der "Business Agility" gar nicht. Blickt man auf die Definition von 2002, so ist dort bereits alles enthalten, was wichtig ist. Mir hilft der Begriff aber bei der Konkretisierung des Einsatzbereichs und der Ausrichtung von Agilität mit meinen Kunden. "Business" weist sie klar darauf hin, dass wir auf eine "globalere" Sicht jenseits von IT, auf den Einsatz und den Grund der Anwendung von Agilität abzielen. Wir setzen den Fokus auf Wertmessung und wollen Vorteile für das ganze Business und das Geschäftsmodell realisieren. Wir berücksichtigen den ganzen Wertstrom und planen den Einsatz agiler Methoden (kosten-)bewusst. Gerade der Rolle des "Agilen Coaches" hilft diese Sichtweise, weil sie Argumentation und die Grundlagen verdeutlicht, mit denen Agilität endlich den Mehrwert und Nutzen bringen kann, den wir uns seit Jahren von ihr versprechen.

Business Agility – vorübergehender Hype oder "Game Changer"?

Die Überlegungen in diesem Artikel haben gezeigt, dass man Agilität und Business-Agilität in dem Sinne, dass sie die gleichen Ideen und Ziele verfolgen, als sehr ähnlich ansehen kann. Der Unterschied liegt darin, dass, als "Agilität" entstand, die Community weder Erfahrungen noch Lösungen hatte, wie Konzepte, die heute unter Business Agility laufen, prozessual oder methodisch umgesetzt werden können. Beispiele dazu sind agile Ende-zu-Ende-Prozesse oder agiles Management auf allen Ebenen im Unternehmen. Der Begriff "Business Agility" verdeutlicht also, dass neue Möglichkeiten existieren, um die altbekannten Ziele der Agilität umsetzen.

Agilität selbst, das Agiles Manifest und die Prinzipien dahinter, haben sich seit 20 Jahren als erstaunlich stabil erwiesen. Neuere Definitionen von Agilität streben mehr oder weniger nur eine Vereinfachung und Verkürzung an [41]. Agilität ist damit unbestritten eine der besten Antworten auf unsere heutige VUCA-Welt. Da Business Agility quasi für die "aktuellsten Antworten" steht, sind die Inhalte höchstrelevant, und zwar für eine Vielzahl von Bereichen und Firmen. Das wird sich wahrscheinlich erst ändern, wenn jemand einen neuen Begriff prägt. Bis dahin gilt: Business Agility rules!

"Agilität ist für uns kein Selbstzweck, sondern ein Mittel zum Ziel. Wir müssen uns schneller dem Wandel unserer Welt anpassen. Mag ja sein, dass es in 20 Jahren dafür andere Methoden gibt – aber hier und heute und für uns ist Agilität die am besten geeignete, um unser Ziel zu erreichen." – Nik Jue, Vorstandsvorsitzender ING Deutschland [42]

Quellen
  1. J. Highsmith, 2002: Agile Software Development Ecosystems, Addison-Wesley
  2. Manifest für Agile Softwareentwicklung
  3. C. Nikos et al, 2002: On the Measurement of Enterprise Agility,  Journal of Intelligent and Robotic Systems
  4. C. Rudd: The Third Wave of Agile
    Deutsche Version
  5. K. Schwabers: The Enterprise and Scrum
  6. SAFe® for Lean Enterprises 5.0
  7. J. Appelo, 2011: Management 3.0
  8. S. Denning, 2010: The Leader’s Guide to Radical Management
  9. E. Ries, 2011: The Lean Startup
  10. J. Appelo: Complexity Theory for Software Developers
  11. Evan’s Theory of Agile Constraints
  12. K. Leopold, 2017: Warum agile Teams nichts mit Business Agilität zu tun haben
  13. Wikipedia: Business agility
  14. Domains of Business Agility
  15. Enterprise agility: Buzz or business impact?
  16. Agile Alliance: Business Agility
  17. Agile Business: Business Agility
  18. SolutionsIQ: The Definition of Business Agility
  19. SAFe: Business Agility
  20. agilityhealth: What Is EBA?
  21. Business Agility Institute
  22. SolutionsIQ: Business Agility Report 2019
  23. Business Agility Institute: Domains of Business Agility
  24. J. P. Kotter, 2011: Leading Change: Wie Sie Ihr Unternehmen in acht Schritten erfolgreich verändern
  25. Business Agility Assessment
  26. SAFe: Measure and Grow, im Bereich "Core Competency Assessment", linke Tabellenspalte
  27. SAFe: Measure and Grow, im Bereich "Core Competency Assessment", rechte Tabellenspalte
  28. agilityhealth: Enterprise Business Agility Model 
  29. SAFe: System Team
  30. G. Hermkes, L. Quintela: Scaling Done Right: How to Achieve Business Agility with Scrum@Scale
  31. P. Merel: XSCALE Business Agility
  32. Less Framework
  33. McKinsey: Enterprise agility: Buzz or business impact?
  34. SolutionsIQ: Unlocking Business Agility
  35. SolutionsIQ: The Definition of Business Agility
  36. Business Agility Works
  37. Agile Business: Business Agility
  38. K. Leopold: Agilität neu denken: Warum agile Teams nichts mit Business Agilität zu tun haben
  39. J. Appelo: Startup, Scaleup, Screwup
  40. Shiftup Workshops
  41. Y. Francino: Modern Agile and Heart of Agile: A new focus for agile development
  42. H. Willenbrock: OAWOW

Autor

Alexander Birke

Alex Birke ist Trainer, Advisor und Konferenzsprecher für Agilität und Lean. Er leitet den agilen Bereich von Accenture, Accenture Business Agility, im deutschsprachigen Raum und ist Lehrbeauftragter.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben