„Agile“ - Von der IT-Methodik zur Universalwaffe

Um es gleich vorwegzunehmen: „Agile“ ist von Haus aus keine abgedroschene Phrase aus dem Management- oder Beratersprech! Trotzdem wird dieser Begriff gerade in jüngster Zeit als Weichmacher missbraucht. Detecon-Experte und Agile Coach Michael Spiller zeigt, was wirklich hinter dem Begriff „Agile“ steckt und welche agile Methoden Sie kennen sollten.

Fehlt die Agenda für die Besprechung? Kein Problem, dann wird es eben ein „agiles Meeting“. Woher diese drastische Fehlinterpretation kommt, weiß keiner. Tatsächlich stehen jedoch hinter dem Begriff „Agile“ sehr klar definierte Prinzipien und Praktiken, mit denen Organisationen effizienter, schneller und flexibler Wert realisieren. Anders ausgedrückt: Agilität setzt geradezu auf Disziplin, um die Anpassungsfähigkeit und Lernfähigkeit zu verbessern.

Agile Methoden wurden zuerst in der IT-Branche eingesetzt und sind dort auch am weitesten verbreitet. Dennoch adaptieren seit einigen Jahren auch Unternehmen anderer Branchen agile Vorgehensweisen. Dafür gibt es mehrere Gründe:

  • Im Zeitalter der Digitalisierung gehören zu fast jedem Produkt IT-Bestandteile.
  • Viele Branchen stehen vor den gleichen Herausforderungen wie die IT-Branche: Kundenbedürfnisse, die sich sehr schnell ändern, sowie technische Lösungen, deren Komplexität und Vielfalt exponentiell anwächst.
  • Die über Jahrzehnte gewachsenen Unternehmensstrukturen und -kulturen können mit den Anforderungen, die sich durch die rasante Geschwindigkeit und Dynamik des Zeitalters der Digitalisierung ergeben, nicht mehr mithalten.

Agile Methoden fördern eine lernende und sich ständig verbessernde Organisation, die sich kontinuierlich an neue Umstände anpassen kann. Dabei wird Verschwendung reduziert und der Förderung von Motivation und Kreativität der Mitarbeiter Raum gegeben. Dies zielt auf Fähigkeiten, die universell gültige Erfolgskriterien für Unternehmen darstellen. Aber wo kommen die agilen Methoden eigentlich her?

Produktentwicklung nach “Rugby”

Agile Methoden wurden zwar zum ersten Mal in IT-Projekten eingesetzt. Die Ursprünge liegen aber tatsächlich ganz woanders: in der Automobilbranche! Getrieben durch den damaligen Produktionsleiter Taiichi Ohno wurde ab dem Jahre 1948 das Toyota Production System (TPS) geschaffen mit dem Ziel, überflüssige Tätigkeiten („Verschwendung“) zu vermeiden und eine hohe Produktivität bei höchster Qualität und kurzen Durchlaufzeiten zu erreichen. Das TPS gilt als „der“ Vorgänger von „Lean“.

Im Jahr 1986 wurde der Artikel „The New New Product Development Game‘ (https://hbr.org/1986/01/the-new-new-product-development-game) im Harvard Business Review veröffentlicht, der einen neuen Ansatz zur Entwicklung von neuen Produkten vorstellte. Die Autoren proklamieren ein Produktentwicklungsvorgehen, bei dem die Entwicklungsphasen überlappen und gesamtheitlich durch ein interdisziplinäres Team getrieben und abgearbeitet werden – ähnlich wie beim Rugby. Im Artikel wird sogar der Begriff „Scrum“ erwähnt – er bezeichnet eine Standardsituation im Rugby, bei dem beide Teams in einem „Gedränge (Scrum)“ versuchen, den Ball nach einem kleinen Regelverstoß oder einer Aussituation wiederzuerlangen. „Scrum“ als Bezeichnung für eine agile Produktentwicklungsmethode war damit geboren.

1988 wurde der Begriff „Lean“ durch einen Artikel zu einer MIT-Studie (https://www.lean.org/downloads/MITSloan.pdf) über die bei japanischen Automobilherstellern vorgefundene, systematisierte Produktionsorganisation geprägt („Lean Manufacturing“, „Lean Production“). In den Folgejahren sind auf dieser Basis Denkprinzipien, Methoden und Verfahrensweisen zur effizienten Gestaltung der gesamten Wertschöpfungskette entstanden. „Lean“-Ansätze zielen darauf ab, alle Aktivitäten, die für die Wertschöpfung notwendig, optimal abzustimmen und überflüssig Tätigkeiten („Verschwendung“) zu vermeiden. Eingang in die Überlegungen finden sowohl die Sicht des Kunden als auch die des Unternehmens.

Die Idee aus „The New New Product Development Game“ wurde schließlich von Ken Schwaber und Jeff Sutherland aufgenommen. Sie stellten ihre mittlerweile weltbekannte, agile Projektmanagementmethode „Scrum“ im Jahr 1995 auf der „Object Oriented Programming, Systems, Languages and Applications“ (OOPSLA) Konferenz in Austin, Texas, vor. Scrum wird schnell zu populärsten und bekanntesten agilen Methode, die von ihren beiden Erfindern kontinuierlich weiterentwickelt und frei verfügbar über den Scrum Guide (https://www.scrumguides.org/) veröffentlicht wird.

 

Das agile Manifest – kulturelles Fundamt jedes agilen Ansatzes

Im Februar 2001 trafen sich 17 Softwareentwickler in Utah, um leichtgewichtige Entwicklungsmethoden zu besprechen. Allen gemein ist ihre Frustration über die Unproduktivität bis dato vorherrschender Methoden. Allerdings fehlt ein konträres Verständnis darüber, wie ein besserer Ansatz konkret aussehen könnte. Sie einigen sich auf neue Leitlinien für die produktivere Entwicklung von Software bedarf – das „Agile Manifest“ mit vier Werten und 12 Prinzipien.

Damit sind nicht nur die Grundlagen der agilen Zusammenarbeitskultur definiert, sondern auch das Fundament aller Ansätze, die diese Kultur in Form von Methoden und Rahmenwerken institutionalisieren wollen. Existierende, mit dem Manifest kompatible Methoden wie eXtreme Programming (kurz: XP) oder Scrum werden ab sofort als „agile“ Methoden bezeichnet. In den folgenden Jahren werden die Ansätze von Lean, welche gezielt auf die Effizienzsteigerung der Wertschöpfungskette abzielen, mit denen der Agilität, welche eher die Arbeitsweise einer Organisation im Kontext Veränderung adressieren, vereint. Es entstehen unter anderem Lean Software Development, Lean Startup und Kanban.

Seit dem agilen Manifest ist "Agile" der Oberbegriff für alle Methoden, die mit den Werten und Prinzipien des Agilen Manifests im Einklang stehen. Leider ist dieses Verständnis durch den schnellen Erfolg agiler Methoden längst nicht überall präsent. Dadurch entstehen (bewusste) missverstandene Anwendungen von „Agile“ in Unternehmen, was dazu führt, dass der Begriff zu einer abgedroschenen Phase missbraucht wird. Viele Praktiken, Methoden oder Prozessvorgehen sind nun mal einfach nicht „agil“, obwohl sie so tituliert wurden. 

Ein Überblick über 50 agile Methoden und Werkzeuge

Agilen Methoden gemein sind die Vermittlung der Ziele, die Verinnerlichung der agilen Werte und die Nutzung vorhandener Werkzeuge und Modelle, die Teilbereiche einer agilen Organisation abdecken. Allen Ansätzen zugrunde liegen darüber hinaus die oben beschriebenen Werte und Prinzipien aus dem agilen Manifest und den Lean (Manufacturing) Ansätzen.

Mittlerweile existiert eine Vielzahl agiler Methoden mit unterschiedlichen Bekanntheitsgraden und verschiedenen Einsatzbereichen. Der australische Agile Coach Craig Smith hat 2015 eine Zusammenstellung agiler Methoden erstellt (https://craigsmith.id.au/2015/12/03/yow-2015-40-agile-methods-in-40-minutes/). Diese haben wir mit den Entwicklungen der vergangenen Jahre zu einer aktuellen Übersicht agiler Methoden und Werkzeuge (Abbildung 1) ergänzt. In der Übersicht ist zu sehen, dass es mindestens 50 agile Ansätze gibt. Nur wenige agile Berater und Coaches kennen diese Vielzahl an nützlichen Praktiken, Methoden und Tools aus diesen Ansätzen. Im Folgenden haben wir die Ansätze in die 5 Kategorien Softwareentwicklung, Produktentwicklung, Vorgehensweisen, Aufbau- und Ablauforganisation sowie Führung gruppiert und fassen die wesentlichen Inhalte zusammen.

Softwareentwicklung

Die meisten agilen Entwicklungspraktiken und -werkzeuge zielen auf Bereiche der Softwareentwicklung, zum Beispiel Anforderungsmanagement, Design, Modellierung, Coding, Testing, Planung, Risiko Management, Softwareentwicklungs- und betriebsprozesse oder Qualitätsicherung. Agile Softwarenentwicklung umfasst Praktiken und Werkzeuge, die den gesamten Softwarelebenszyklusprozess effizienter gestalten.

Der DevOps-Ansatz fasst die Betrachtungsfelder im CALMS-Rahmenwerk in fünf Disziplinen zusammen:

Culture: Es wird eine Kultur der geteilten Verantwortung und effektiven Zusammenarbeit aller Beteiligten vor allem aus Entwicklung, Betrieb und immer mehr auch aus dem Fachbereich etabliert. Dieser Kulturwandel zielt auf die eine schnellere und zuverlässige Entwicklung und Lieferung von IT-Lösungen ab.

Automation: Teams suchen nach Möglichkeiten, um so viele Aufgaben wie möglich zu automatisieren, und leben die Idee der kontinuierlichen Integration und Bereitstellung. Damit sollen schnelle Lieferung, schnelleres Lernen, schnellere Reaktion auf Marktanforderungen und Kundenfeedback, hohe Produktivität und Sicherheit ermöglicht werden. Automatisierung beinhaltet auch die Erstellung wiederholbarer Umgebungen und Prozesse, die sich selbst dokumentieren und daher leichter zu verstehen, zu verbessern, abzusichern und zu überwachen sind.

Lean: Teams können laufende Arbeiten (WIP: Work in Progress) visualisieren, Losgrößen reduzieren und Warteschlangen verwalten. Damit soll ein kontinuierlicher Fluss an Wertlieferung, das heißt schnellere Lieferung neuer Funktionalität und damit kürzere Markteinführungszeiten, erreicht werden.

Measurement: Teams messen möglichst alles im Softwarelebenszyklus und haben volle Transparenz über die erhobenen Messdaten. Messungen in der kontinuierlichen Lieferkette (Continous Delivery Pipeline) zielen darauf ab, während der Entwicklung und im Betrieb schnell auf Abweichungen aufmerksam zu werden. Echtzeitdaten sollen automatisiert zur Performance von IT-Lösungen erfasst und ausgewertet werden. Somit sollen Auswirkungen von Änderungen am System schnell bewertbar und im Problemfall lösbar sein. Neben der technischen Leistung einer IT-Lösung soll aber auch die tatsächliche Nutzung durch die Nutzer gemessen werden, um Nutzungshypothesen zu evaluieren und Potentiale von Verbesserungen der Nutzererfahrung zu identifizieren.

Sharing: Benutzerfreundliche Kommunikationskanäle fördern die ständige Kommunikation zwischen Entwicklung, Betrieb und Fachseite, um ein einheitliches Nutzenverständnis zu fördern. Wissensaustausch und Zusammenarbeit sind entscheidend für die konstruktive und iterative Basis, die angestrebt wird. Wissens- und Erfahrungsaustausch auch über die eigenen Team- und sogar Unternehmensgrenzen hinweg soll einen Blick über den eigenen Tellerrand hinaus fördern.

Das agile Organisationsrahmenwerk SAFe betont noch eine weitere Disziplin: (https://scaledagileframework.com/devops/)

Recovery: Teams sind in der Lage, Probleme nach einer Auslieferung schnellstmöglich zu beheben. IT-Lösungen werden beginnend bei der Konzeption und Architektur über die gesamte Lieferkette hinweg für Bereitstellungsfähigkeit, Freigabefähigkeit und schnelle Wiederherstellung nach Betriebsstörungen optimiert. Damit sollen Releases so risikoarm wie möglich werden, um die kontinuierliche Bereitstellung zu ermöglichen und eine bedarfsgerechte Freigabe von Funktionalität an den Nutzer zu unterstützen.

Die in Abbildung 1 aufgeführten Ansätze unterstützen die Umsetzung der vom DevOps-Ansatz definierten Disziplinen. Methoden wie eXtreme Programming bringen darüber hinaus auch viele Werkzeuge zum Einsatz in agilen Vorgehensweisen (siehe Abschnitt „Vorgehensweisen“).

Überblick über agile Ansätze

Abbildung 1

Produktentwicklung

Neben den auf Softwareentwicklung fokussierten Ansätzen gibt es auch agile Methoden und Werkzeuge für die allgemeine Produktentwicklung. Hier geht es im Kern darum, Produktentwicklungszyklen zu verkürzen und so effizient wie möglich auszugestalten. Es soll schnell herausgefunden werden, ob ein vorgeschlagenes Geschäftsmodell funktioniert, anzupassen oder gar einzustellen ist („fail fast“). Weiterhin wird der Wert für den Nutzer als auch für das eigene Unternehmen ins Zentrum gestellt und ein Verständnis darüber geschaffen, welche Probleme und Bedarfe Produkte und Produktteile adressieren. Ist das erreicht, soll auch die Priorisierung und damit die Sequenzierung der Entwicklung auf Basis einer objektiven auf Wertschaffung im Verhältnis zu Aufwand basierenden Metrik erfolgen.

Vorgehensweisen

Agile Vorgehensweisen, häufig auch als agile Projektmanagementmethoden bezeichnet, zielen auf die schnellere, flexiblere und effizientere Abarbeitung eines Vorhabens. Daher eignen sie sich sowohl für langfristige Aufträge, zum Beispiel die Begleitung des gesamten Produktlebenszyklus, als auch für zeitlich limitierte Umfänge, zum Beispiel Projektmanagement. Längst haben Vorgehensweisen ihre anfängliche Ausrichtung auf Software überwunden und lassen sich branchen- und themenübergreifend einsetzen. Fast alle agilen Vorgehensweisen sind iterativ-inkrementell: in festen zeitlichen Intervallen von wenigen Wochen (Iterationen) werden möglichst voll funktionsfähige Produktteile (Produktinkremente) erstellt. Eine Produktvision gibt dabei die Zielrichtung vor. Am Ende einer Iteration werden die erstellten Produktinkremente dem Fachbereich und noch besser dem Kunden vorgestellt, Feedback eingeholt und auf dessen Basis die nächste Iteration geplant. Dadurch sind Anpassungen aufgrund von Erkenntnisgewinn zulässig und sogar gewünscht. Einmal gestartete Iterationen sollen sich vom Umfang her möglichst nicht ändern um neben der Flexibilität auch Fokussierung und Lieferfähigkeit sicherzustellen. Im Regelfall wird die Arbeit einer Iteration visualisiert und die Menge der gleichzeitig laufenden Arbeiten (WIP: work in progress) limitiert, um einen schnellen Wertfluss zu ermöglichen.

Agile Vorgehensweisen fördern selbstorganisierte Hochleistungsteams. Die Teamzusammenarbeit wird mindestens einmal in jeder Iteration verbessert. Durch höhere Autonomie und Entscheidungskompetenz soll die Motivation und Handlungsfähigkeit des Teams gestärkt werden. Kommunikation, Abstimmung und Synchronisation im Team wird durch schlanke Planungs- und Ergebnispräsentationstermine sowie prägnante Fortschrittsabstimmungen gefördert. Ist mehr als ein Team mit der Arbeit beschäftigt, stimmen sich Teams mit Abhängigkeiten regelmäßig ab und können über eine übergeordnete Produktvision auf ein gemeinsames Ziel hin ausgerichtet sein. Um den Lösungsraum nicht zu früh einzuschränken, werden Anforderungen aus Nutzersicht und unter Beschreibung des Nutzerbedarfs definiert. Mittlerweile haben sich hierzu „User Stories“ etabliert – ein ursprünglich aus eXtreme Programming entstammendes Werkzeug. Mit der Zeit haben sich auch Schätzverfahren wie Planning Poker oder White Elephant Sizing entwickelt, damit Aufwandsschätzungen vom Team selbst und möglichst effizient getroffen werden können. Agile Vorgehen priorisieren nach dem Verhältnis von Wert zu Aufwand und fördern in diesem Kontext Gespräche zwischen Entwicklung und Fachbereich über den wirtschaftlichen Umfang der Produktinkremente. Am häufigsten arbeiten agile Teams derzeit mit Scrum, Kanban oder Weiterentwicklungen von diesen Ansätzen.

Aufbau- und Ablauforganisation

Während die gerade vorgestellten agilen Vorgehensweisen nur ein oder wenige Teams betrachten, geht es bei agilen Methoden zur Aufbau- und Ablauforganisation darum, die agilen Werte und Prinzipien auf größere Organisationsteile oder sogar die Gesamtorganisation zu erweitern. Die in diese Kategorie fallenden Ansätze werden häufig auch als „agile Skalierungsrahmenwerke“ bezeichnet. Im Wesentlichen unterscheiden sich die Ansätze in ihrer Skalierbarkeit und in ihrer Komplexität oder dem Umfang an Artefakten. Eine Gegenüberstellung gängiger Skalierungsrahmenwerke und Vorgehensweisen nach diesen beiden Kriterien haben wir in Abbildung 2 vorgenommen.

Vergleich bekannter agiler Rahmenwerke

Abbildung 2

Im Mittelpunkt dieser Ansätze stehen die Koordination und Synchronisation von Zielen, Arbeit und Abhängigkeiten zwischen agilen Teams. Dabei werden zunächst Wertströme betrachtet, also alle Aufgaben und Akteure, die zur Entwicklung, Lieferung und zum Betrieb von Produkten benötigt werden. Diese Wertströme werden durch alle benötigen Fähigkeiten in Form von agilen Teams operationalisiert. Dahinter steht das Prinzip, dass in einer agilen Organisation die Arbeit zu den Mitarbeitern und nicht die Mitarbeiter zu der Arbeit gebracht werden. Projekte werden somit obsolet und deren administrativer Aufwand (Budgetierung, Personalbesetzung) massiv reduziert.

Die fachliche Zieldefinition und Synchronisation findet durch Produktverantwortliche auf mehreren Abstraktionsebenen (Gesamtprodukt, Systemebenen, Komponentenebenen) statt. Manche Ansätze definieren noch Expertengruppen oder Rollen für die Definition und Kommunikation von Leitplanken zu Architektur, Entwicklung und User Experience. Damit soll sichergestellt werden, dass der Nutzer das Gefühl von einem durchgehenden Produkt erhält und alle Produktteile zusammenpassen.

In einer agilen Organisation wird der Wert in Form von zu adressierenden Nutzerbedarfen hinterfragt und als Kontextinformation in Form von Visionen, Roadmaps und Anforderungsbeschreibungen, beispielsweise durch Epics, Features und User Stories bis zum agilen Team transportiert. Durch effiziente Schätzungen von Fach- und Entwicklungsexperten wird auf allen Ebenen durch Priorisierung sichergestellt, dass an den richtigen Themen zur richtigen Zeit gearbeitet wird. Manche Rahmenwerke adressieren auch die Strategie- und Portfolioebene, auf der ebenfalls durch Zusammenarbeit von Expertengruppen schlanke Geschäftsmodelle aufgestellt, in Produktinkremente heruntergebrochen und kontinuierlich über Feedback-Zyklen priorisiert werden. Dabei kommen Ansätze aus den agilen Produktentwicklungsansätzen wie das Minimum Viable Product (MVP), also der geringstmögliche Produktumfang zum Erlangen von qualifiziertem Feedback, und das Minimum Marketable Feature (MMF), der minimale für den Marktangang erforderliche Funktionsumfang, zum Einsatz. Ziel ist es, möglichst schnell die technische Realisierbarkeit sowie die Markfähigkeit zu prüfen, um umgehend darauf reagieren zu können. Daher fördern agile Organisationen auch Kommunikation, Transparenz, Abstimmung und Synchronisation auf und zwischen allen Ebenen bei gleichzeitiger Beschränkung dieser auf das nötigste.

Die aktuell bekanntesten und bei unseren Kunden am häufigsten eingesetzten Rahmenwerke sind SAFe und LeSS. Das Scaled Agile Framework (SAFe) zeichnet sich durch die hohe Skalierbarkeit, den großen Umfang und die Berücksichtigung einer Vielzahl von agilen Methoden und Werkzeugen aus. Dadurch besteht allerdings die Gefahr, zu sehr auf den Vorgaben des Rahmenwerks zu verharren und die eigene Adaption zu vernachlässigen. Es ist aus unserer Sicht wichtig, SAFe als umfangreichen Werkzeugkasten anzusehen, dabei aber die Flexibilität sowie weitere Werkzeuge aus anderen Rahmenwerken nicht aus den Augen zu verlieren.

Rahmenwerke wie Large Scale Scrum (LeSS) oder Scrum@Scale sind weit schlanker als SAFe und damit leichter adaptierbar. Sie erfordern dadurch aus unserer Sicht einen höheren Reifegrad der Organisation in agiler Zusammenarbeit und Selbstorganisation. Darüber hinaus ist die Adaption mit Aufwand verbunden, der häufig bei einer agilen Transformation nicht gesehen und damit auch nicht eingeplant wird.

Das Spotify-Modell wird übrigens häufig missverstanden: Es handelt sich hierbei nicht um ein Rahmenwerk, sondern um ein Beispiel beziehungsweise eine Momentaufnahme von Erfahrungswerten, wie eine agile Organisation für ein spezifisches Unternehmen und deren Geschäftsmodell aussehen kann. Das heißt, dass Anregungen aus dem Modell herausgezogen werden können, für die eigentliche Ausgestaltung und damit den Startpunkt eines eigenen Ansatzes aber Rahmenwerke mit ihrem größeren Freiraum geeigneter sind.

Führung

Es gibt mittlerweile eine Vielzahl an Ansätzen, die lean-agile Werte und Prinzipien auch in der Führung von Organisationen verankern. Grundsätzlich geht es darum, dass Führung in fachliche Führung und personelle Förderung und Entwicklung aufgeteilt wird. Zielsetzung ist dabei, die gesamte Unternehmung systemisch so auszugestalten, dass die Mitarbeiter optimal an der Wertschöpfung arbeiten können und Verschwendung kontinuierlich reduziert wird. Die fachliche Führung konzentriert sich dabei auf:

  • Wertorientierung: Führungskräfte sind für die Exploration und Evaluation von wertschöpfenden Vorhaben auf allen Ebenen verantwortlich. Diese werden in Form von Zielen und Messkriterien – zum Beispiel mittels Objective and Key Results (OKRs) – kommuniziert. Budgetierung wird auf Wertströme und damit Produkte vorgenommen. Ständiges Lernen heißt, dass Vorhaben kontinuierlich evaluiert und an Erkenntnisgewinne angepasst werden.
  • (Intrinsische) Motivation: Führungskräfte vermitteln den Mitarbeiten die Sinnhaftigkeit von Vorhaben durch ständige Entwicklung und Kommunikation von Visionen und Missionen. Die Dezentralisierung von Entscheidungskompetenz und das Ausräumen von Hindernissen tragen zusätzlich dazu bei.

Bei der personellen Führung steht die Mitarbeiterentwicklung im Vordergrund. Führungskräfte definieren gemeinsam mit dem Mitarbeiter individuelle Karriereentwicklungen und unterstützen diese fortlaufend. Dabei geht es um das Hochhalten von Veränderungsbereitschaft und den individuellen Aufbau von passenden Fähigkeiten und Fertigkeiten.

Einzelne Verantwortungen von Führungsrollen sollen dezentralisiert und in die einzelnen Wertströme oder Teams übergeben werden. Mitarbeiter werden stärker in Entscheidungsprozessen eingebunden. Führungskräfte sind dafür aber stärker zum Verständnis des Marktes und der Ableitung von Bedarfen und Bewertung von Lösungsideen gefordert. Strategische, langfristige und weitreichende Entscheidungen werden weiterhin zentral gefällt, dies sollte aber verstärkt durch Expertengruppen erfolgen. Alle anderen Arten von Entscheidungen werden dezentral durch die jeweiligen Rollen und Mitarbeiter mit dem benötigten Wissen getroffen.

Da die Anforderungen an Führung in lean-agilen Organisation die bisherige Ausprägung des Managers als Verwalter obsolet macht, handelt es sich hierbei um eine der größten Herausforderungen der agilen Transformation in vielen Unternehmen.

 

Fazit: Agil kann nur helfen, wenn es verstanden wird

Agile ist also kein Modewort, sondern eine stetig umfangreicher werdende Sammlung von funktionierenden Rahmenwerken, Methoden und Werkzeugen zur Optimierung aller Organisationsebenen in Richtung flexible und effiziente Wertschöpfung. Ansätze dann agil, wenn sie den Werten und Prinzipien des agilen Manifests sowie des Lean (Manufacturing) entsprechen. Vor dem Einsatz dieser mächtigen Ansätze ist es wichtig, dass ein Unternehmen versteht, was Agilität exakt bedeutet und welche Probleme es damit lösen will oder in welchen Disziplinen es besser werden möchte oder muss. Leider reicht es nicht aus, bestehende Rahmenwerke eins zu eins zu übernehmen. Eine agile Transformation ist langfristig nur dann erfolgreich, wenn sie maßgeschneidert auf die Anforderungen des Unternehmens erfolgt.