Agiles Projektmanagement _ Grundlagen, Methoden und Einführung

Grundlagen und Entwicklung agiler Methoden

Agiles Projektmanagement ist eine Alternative, ein dritter Weg zu 

  1. den traditionellen Methoden zum Planen und Durchführen von Projekten und
  2. einer Arbeitsweise, die darauf verzichtet, den Projektverlauf zu planen und zu strukturieren (Ad-hoc-Vorgehen).

Die Grundlagen agilen Arbeitens sind:

  • agile Werte,
  • agile Prinzipien und
  • agile Praktiken.

Werte und Prinzipien wurden um die Wende des Jahrtausends formuliert. Agile-Pioniere beobachteten dazu das Vorgehen erfolgreicher Entwickler-Teams in Software-Projekten.

Setzt eine Organisation agiles Projekt­management ein, nutzt sie „agile Vorgehens­modelle“. Ein agiles Vorgehens­modell ist eine Kombination verschiedener agiler Praktiken zu einer Methode.

Das am weitesten verbreitete agile Vorgehens­modell ist Scrum.

Wir wollen hier zwei wichtige Fragen klären:

  1. Worauf kommt es beim agilen Projekt­management wirklich an? Das Meistern der agilen Techniken oder Praktiken? Oder doch eher das Verständnis der Grund­prinzipien? Und auf Kreativität und Flexibilität im Umgang damit?
  2. Wie funktionieren agile Methoden außerhalb der Software-Programmierung? Bei Digitali­sierungs­projekten, Bürokratie­abbau oder der Produkt­ent­wicklung. In Branchen wie Versicherungen, Handel, Maschinen­bau oder Chemie.

Projekte, die nicht von agilen Methoden profitieren

Bei vielen Projekten wird das Projektergebnis zum Projektbeginn festgeschrieben. Dies geschieht in der frühen Projektphase, der Projektdefinition. Der Bau eines Hauses ist ein Beispiel. Zuerst entwickeln Architekt und Fachingenieure den detaillierten Bauplan. Anschließend wird die Ausführung geplant. Der Plan legt fest, welches Gewerk in welchem Zeitabschnitt erstellt wird.

Es gibt eine Reihenfolge, die einzuhalten ist: Das Fundament muss fertig sein, bevor der Rohbau beginnen kann. Der fertige Rohbau ermöglicht den Beginn des Innenausbaus.

Halten wir wichtige Merkmale eines solchen Projektes fest:

  • Das Projektergebnis und seine Eigenschaften können vor Umsetzungsbeginn beschrieben und festgelegt werden.
  • Die Projektschritte (Gewerke) müssen einer festen Reihenfolge folgen.
  • Dauer und Aufwand der einzelnen Abschnitte und Aufgaben werden mit Hilfe von Erfahrungswerten geschätzt und geplant.
  • Die Projektressourcen (Handwerker im Beispiel) müssen Monate vorher wissen, wann sie an der Reihe sind. Nur so können sie ihre Kapazitäten und Aufträge planen.
Rhein-Main-Neckar-Spezial-Angebote
Mainz, Darmstadt, Bergstraße, Mannheim, Ludwigshafen, Heidelberg, Karlsruhe und Umgebung
Rhein-Main-Neckar-Special

Typische Projekte für agiles Management

Bei einem anderen Projekt-Typ spielen Unsicherheit und Komplexität eine wichtige Rolle. Unsicherheiten über 

  • Dauer und Umfang der zu erledigenden Arbeit und der Teilaufgaben.
  • Anforderungen, Erwartungen und Bedürfnisse der Projektkunden und anderer „Stakeholder“.
  • Ideen und Erkenntnisse, die sich im Projektverlauf ergeben werden.

In diese Kategorie fallen die meisten Change-, Entwicklungs- und Innovationsprojekte. Bei ihnen sind frühe, detaillierte Festlegungen weder möglich noch zielführend.

Für diesen Projekttyp ist das agile Projektmanagement die Methode der Wahl.

Glossar der agilen Begriffe

  • Was ist ein Sprint, eine User Story?
  • Was macht ein Product Owner? 

Die 50 wichtigsten Begriffe, die Sie kennen sollten. 

Die Grenzen des Planens

Umfangreiche Projekte werden klassisch mit Hilfe spezieller Software gesteuert. Nachdem alle Planungsdaten erfasst sind, erzeugt die Software einen Ablaufplan; als Tabelle oder als Diagramme. Üblich sind Balkendiagramme (Gantt-Diagramme) und Netzpläne (PERT-Diagramme).

Die Diagramme zeigen den Projektmitarbeitern, von wann bis wann sie welche Projektaufgaben erledigen sollen. Projektmanagern helfen sie, die fristgerechte Erledigung zu überprüfen. 

Dauert eine Aufgabe länger als geplant,  sucht die Projektleitung nach Wegen, die Auswirkungen auf die folgenden Aktivitäten und den Gesamtplan zu minimieren. Sie gibt die Verzögerung in die Planungssoftware ein – und diese berechnet dann einen “neuen” Plan.

Leider ruft der neue Plan meist Konflikte mit anderen Projektressourcen hervor: Verspätet sich der Elektriker mit der Verlegung der Elektroleitungen, können die Putzer und Maler erst später anfangen. Zu ihrem neu berechneten Termin haben sie aber schon einen anderen Auftrag angenommen. Eine Planabweichung ruft so einen Dominoeffekt hervor.

Anders, wenn ein Haus in Eigenleistung, mit Freunden und Verwandten gebaut wird. Die sind erstens flexibler und zweitens „multifunktional“. Das heißt, der Einzelne kann für mehrere Gewerke eingesetzt werden.

Bei so einem Projekt wird man mehr Merkmale des agilen Projektmanagements beobachten können. 

Ja, mach nur einen Plan!
Sei nur ein großes Licht!
Und mach dann noch ’nen zweiten Plan
Gehn tun sie beide nicht.

Ballade von der Unzulänglichkeit menschlichen Planens (Dreigroschenoper)

Kurzer Wissens-Check

Wir sehen am Beispiel des Hausbaus, dass traditionelle Projekte hohe Planbarkeit verlangen. Das Projektergebnis steht bei Umsetzungsbeginn fest. Es ist detailliert beschrieben.

Traditionelles Management bedingt, dass „das Projekt diszipliniert dem Plan folgt“. Überraschungen sind nicht vorgesehen.

Klassische Planung ist nötig, wenn wichtige Projektressourcen spezialisiert sind und Terminpflichten ausserhalb des Projektes haben.

Solche Projektressourcen können, bei Bauprojekten, Handwerker und Subunternehmer sein.

Bei Entwicklungsprojekten kann es sich um 

  • ein Labor oder eine Testanlage,
  • externe Dienstleister,
  • Experten, die in mehreren Projekten parallel arbeiten oder
  • Mitarbeiterinnen, die dem Projekt nur zeitweise zur Verfügung stehen

handeln.

  • Projekte, bei denen das Ziel, das Projektergebnis nicht sehr früh konkretisiert und fixiert werden kann. 
  • Projekte, bei denen vom Start zum Ziel Überraschungen zu erwarten sind.

Was bedeutet "iterativ-inkrementell" im agilen Projektmanagement?

Inkrementelles Entwickeln von (nutzbaren) Teilen

Beim Entwickeln in Inkrementen wird das Produkt gedanklich in Teile (= Inkremente) zerlegt. Die Teile werden einzeln entwickelt und später zusammengefügt.

Wunderbar illustriert wird das durch Jeff Pattons’ Beispiel der Mona Lisa.

Das Zerlegen von Aufgaben in Teilaufgaben ist auch im klassischen Projektmanagement üblich.

In agilen Projekten haben wir zwei Besonderheiten:

Wir arbeiten nicht mit Aufgaben, sondern mit testbaren Produktteilen. Was testfähig bedeutet, hängt vom Projektthema ab.

Entwickelte Teile werden den Projektkunden präsentiert. Ein Bericht genügt nicht. Die Stakeholder sollen Resultate anschauen, anfassen, ausprobieren. Und dann ihre Eindrücke und Bewertungen berichten; genau wie Ideen, die sie dabei haben. Bei abstrakten Projektthemen müssen die entwickelten Inkremente kreativ „erlebbar“ gemacht werden.

Da Vinci hätte einen Kopf der Mona Lisa als Teil des Ganzen gemalt und seinem Auftraggeber gezeigt. Der hätte vielleicht Änderungswünsche gehabt, wie:

  • ein anderes Größenverhältnis zwischen Figur und Hintergrund.
  • eine andere Stimmung durch gedämpfte Farben.
  • ein anderer Gesichtsausdruck.

Es fällt Anwendern schwer, auf Anfrage ihre eigenen Bedürfnisse zu begreifen und in Worte zu fassen.

Einfach ist dagegen, eine Vorlage zu kritisieren und Änderungswünsche zu formulieren. Und im agilen Projekt machen wir das in mehreren Schleifen.

Iterationen: schrittweise immer mehr Qualität und Details

Bei iterativer Vorgehensweise arbeiten wir in mehreren Feedback-Schleifen. Jede Schleife, jede Iteration wird konkreter, detaillierter, hat eine höhere Qualität.

Auch Iterationen sollen nutz-, test-, bewertbar sein.

Am Beispiel der Mona Lisa: Schon die Skizze (Stufe 1) kann ein marktfähiges Produkt sein.

Der Auftraggeber kommentiert die erste Iteration vielleicht so:

  • Die Darstellung soll mehr von der Landschaft zeigen.
  • Die Körperhaltung soll aktiver, dynamischer sein.
  • Der Standpunkt des Betrachters soll tiefer liegen, damit mehr Himmel ins Bild kommt.

Zum Mitdenken (Stift und Papier empfohlen)

Vielleicht versuchen Sie einmal zu skizzieren, in welchen (4 bis 6) Haupt-Iterationen eins dieser zwei Projekte durchgeführt werden könnte:

  • Ein Change-Projekt, durch das Teams im Vertriebsinnendienst als selbstorganisierte Teams arbeiten.
  • Ein Entwicklungsprojekt für einen neuen, innovativen Prozess zur Personalbeschaffung.

Agiles Projektmanagement und iterativ-inkrementelles Vorgehen

Keine Überraschung hier: Iterativ-inkrementell kombiniert die beiden vorherigen Ansätze. Einzelne Teile des Gesamtvorhabens werden in Qualitätsstufen entwickelt; bis das Gesamtpaket in der gewünschten Qualität umgesetzt ist. In Scrum-Projekten wird am Ende eines Sprints ein testbares Ergebnis geliefert. Mindestens eins, das dem Team und den Projektkunden zu neuen Einsichten oder Ideen verhilft.

Anforderungen in sinnvolle Teile und Qualitätsstufen zu zerlegen ist plausibel. Es bei verschiedenen Projektthemen elegant zu nutzen, lernen Agilisten mit der Zeit und zunehmender Routine.

Vorteile des iterativ-inkrementellen Vorgehens?

Beim rein inkrementellen Projektablauf muss das Endprodukt schon zu Beginn definiert sein. 

Beim iterativen Ablauf können wir auf Grundlage einer relativ vagen Idee beginnen zu arbeiten. Wir machen etwas und holen Feedback dazu ein. Wir überlegen dann, ob wir darauf aufbauend weiter machen. Oder ob wir das Gelernte nutzen, um den bestehenden Teil noch einmal anders neu zu machen oder ihn zu verändern. 

Ein großer Vorteil: Da wir nicht gleich den gesamten Entwicklungsaufwand betreiben, können wir alternative Varianten entwickeln und testen.

Um Agiles Projektmanagement erfolgreich zu nutzen ...

Agile Methoden setzen sich durch

Das bestätigt eine Forrester-Studie schon 2013:

„Agilität […] setzt sich außerhalb der Software-Entwicklung durch. Manche Unternehmen setzen Agile in Bereichen ein, wie:

  • Portfolio-Management
  • Projektmanagement
  • Lieferanten-Management
  • Beschaffung […]“

Für agil durchgeführte Projekte sind zahlreiche Vorteile belegt. Dazu gehören Geschwindigkeit, Kosteneinsparungen, Produktivität, höhere Anwender-/Kundenorientierung.

Agiles Projektmanagement liefert unter anderem in diesen Branchen

  • Automobilindustrie
  • Automobilzulieferer
  • Dienstleistungen
  • Finanzen und Versicherungen
  • Einzelhandel
  • Maschinenbau
  • Chemieindustrie
  • Lebensmittelindustrie
  • Medizintechnik
  • Kunststoffverarbeitung
  • Metallverarbeitung
  • Spielwaren
  • Pharmazie

Das agile Manifest

Im agilen Manifest sind die 4 fundamentalen Werte des agilen Projektmanagements und des agilen Arbeitens definiert. Das Format ist eine Gegenüberstellung von klassischen PM-Paradigmen und den agilen Positionen.

Dabei geht es nicht um Schwarz-Weiß-Denken. Klassische Paradigmen, wie standardisierte Prozesse, einheitliche Werkzeuge oder detaillierte Dokumentation, sollen nicht abgeschafft werden. Sie sollen im agilen Projekt lediglich die agilen Paradigmen nicht dominieren.

Die richtige Balance ändert sich von Projekt zu Projekt, auch abhängig von den Fähigkeiten der Teams und den Rahmenbedingungen der Organisation.

📌 Klicken Sie auf die 4 agilen Werte unten, um Beispiele und Erläuterungen zu sehen.

Agile Werte

Definierte Prozesse und einheitliche Werkzeuge sind perfekt für sich wiederholende Abläufe. Ist das Ziel jedoch, etwas Neues, Innovatives zu entwickeln, schränken sie oft zu sehr ein oder funktionieren nicht. 

Im agilen Projektmanagement sind die Erfolgstreiber:

  • menschlicher Einfallsreichtum, menschliche Vorstellungskraft und
  • flexible, motivierte Teamarbeit.

Die damit verbundenen Freiräume für Teams und Einzelne ermöglichen die Leistungen, die erfolgreiche agile Projekte ausmachen.

In Produktinkrementen und/oder -iterationen manifestierte Anforderungen sind Grundlage für weiteres Verbessern. Oft haben sie auch schon einen wirtschaftlichen Wert. 

Detaillierte Dokumentation dagegen friert den Status ein. Um das bestmögliche Projektergebnis zu erzeugen, brauchen die Entwickler Freiheit und Flexibilität weit in das Projekt hinein.

Bei klassischen Auftragsprojekten wird über Pflichtenhefte, Lastenhefte und Spezifikationen das zu liefernde Produkt in Verhandlungen genau definiert. Das soll Risiken und Nachteile für beide Parteien reduzieren. Ganz besonders geht es um das Risiko von Nachforderungen. Jede Partei versucht, sich für den Fall einer gerichtlichen Auseinandersetzung eine starke Position zu verschaffen. 

Das ganze Verfahren ist sehr aufwändig. Wenn neue Erkenntnisse im Projektverlauf zu Änderungen des Projektziels führen, entstehen trotzdem neue Unsicherheiten.

Eine agile Zusammenarbeit zwischen Auftragnehmer und Auftraggeber geht dagegen in Schritten vor. Das kann etwa so gestaltet sein:

Beide Parteien einigen sich darauf, das Projekt mit agilem Projektmanagement durchzuführen. Sie legen zu Beginn jeder Arbeitsphase die Vergütung und eine Liste priorisierter Teil- und Zwischenergebnisse fest. Neben den praktischen Ergebnissen der Phase hat an deren Ende:

  • der Auftragnehmer bessere Informationen zum Aufwand und
  • der Auftraggeber bessere Informationen über Resultate, die er nach einem definierten Zeitraum und für ein definiertes Budget erwarten kann.

Auf der Grundlage werden wieder eine priorisierte Liste und ein Budget für die nächste Phase vereinbart.

Im agilen Projektmanagement wird das Projektergebnis in Lernschleifen entwickelt.

Dieses Prinzip bedingt bereits, dass Ergebnisse und Erkenntnisse einer Arbeitsphase Einfluss haben auf:

  • die Ziele und damit
  • die Aktivitäten folgender Arbeitsphasen.

Während Änderungen von Anforderungen in klassichen Projekten ein Störfaktor sind, sind sie für das agile Mindset positiv.

Sie sind eine Gelegenheit, die Bedürfnisse der Projekt-Stakeholder noch besser zu bedienen.

Beim Wechsel von traditionellen Methoden zum agilen Projektmanagement erfordert dies ein neues „mindset“. Ist der Übergang geschafft, wird das neue Paradigma als befreiend erlebt.

12 Agile Prinzipien

Aus den 4 agilen Werten werden 12 agile Prinzipien abgeleitet. Die Prinzipien beschreiben, wie die Werte in agilen Projekten auf der Verhaltensebene umgesetzt werden.

Jedes der Prinzipien kann einer der folgenden Kategorien zugeordnet werden:

  • Erfüllung der Kundenbedürfnisse,
  • Ergebnisqualität,
  • Teamarbeit und
  • Projektsteuerung.

Die ursprünglichen Formulierungen beziehen sich explizit auf Software-Projekte. Unser Wortgebrauch berücksichtigt, dass agiles Projektmanagement mittlerweile weit über IT-Projekte hinaus genutzt wird.

Kontinuierlich liefern
Die höchste Priorität ist, dem Kunden früh und laufend werthaltiges Produkt zur Verfügung zu stellen. (Erfüllung der Kundenbedürfnisse)​​
Änderungen begrüßen
Die Änderung von Anforderungen ist willkommen, selbst spät im Projekt. (Ergebnisqualität, Erfüllung der Kundenbedürfnisse)
Kurze Intervalle
Liefere regelmäßig nutzbares Produkt. In möglichst kurzen Intervallen von wenigen Wochen oder Monaten. (Projektsteuerung)​
Zusammenarbeit
Geschäftsseite und Entwickler müssen täglich zusammenarbeiten. Von Beginn bis zum Ende des Projekts. (Teamarbeit)
Menschen machen den Unterschied
Gestalte Projekte um motivierte Menschen herum. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen. Und vertraue ihnen, dass sie ihre Aufgabe erledigen werden.
Persönliches Gespräch
Der beste Weg, um Informationen in das Team hinein - oder innerhalb des Teams - zu transportieren, ist das persönliche Gespräch. (Teamarbeit)
Fortschritt messen
Nutzbare Ergebnisse sind die primäre Maßeinheit für Fortschritt. (Projektsteuerung)
Nachhaltiges Tempo
Agiles Projektmanagement fördert nachhaltige Entwicklung. Sponsoren, Entwickler und Anwender sollen in der Lage sein, das Arbeitstempo langfristig durchzuhalten. (Teamarbeit, Projektsteuerung)
Qualität
Ständige Beachtung von technischer Exzellenz und gutem Design steigert die Agilität. (Qualität)
Einfachheit
Einfachheit hier ist die Kunst, die Menge an nicht erforderlicher Arbeit zu maximieren und ist essentiell. (Projektsteuerung)
Selbstorganisierte Teams
Die besten Konzepte, Anforderungen und Designs sind das Resultat selbstorganisierter Teams. (Teamarbeit)
Kontinuierliche Verbesserung
In regelmäßigen Abständen überlegen Teams, wie sie effektiver werden. Die Erkenntnisse setzen sie um und passen sich an. (Teamarbeit, Projektsteuerung)

Agile Praktiken

Agile Praktiken konkretisieren noch einmal die agilen Prinzipien bis hin zu Handlungsanweisungen. Ein Beispiel:

Aus dem 12. agilen Prinzip leitet sich, zum Beispiel, die agile Praktik der Retrospektiv-Besprechungen ab. Diese werden, beispielsweise bei Scrum, nach jeder Arbeitsphase, jedem Sprint als Teambesprechung abgehalten. 

In den Retrospektiven (kurz: Retros) suchen die Entwickler nach Wegen, die Geschwindigkeit zu erhöhen. Also in den nächsten Arbeitsphasen ein größeres Volumen an Teil- und Zwischenergebnissen zu entwickeln.

Agiles PM für nicht-IT-Projekte

Bei den meisten Software-Entwicklungen besteht das Endresultat aus zwei Schichten: Programmcode und Datenbanken. Mit der Erstellung des Codes und der Datenbanken ist das Produkt gleichzeitig entwickelt und produziert. 

Industrielle Entwicklung ist meist vielschichter. Das Ergebnis eines Entwicklungsprojektes kann aus diversen “Modulen” bestehen. Die Module interagieren sowohl im fertigen Produkt als auch während der Entwicklung miteinander.

Dadurch ist der Koordinationsbedarf zwischen den verschiedenen “Entwicklungssträngen” oft viel größer als bei Softwareprodukten. Solche Schichten, oder Entwicklungsstränge können sein:

  • das technisch-physische Produkt,
  • ein funktional-ästhetischen Produktdesign,
  • ein Verpackungsdesign,
  • gekoppelte Dienstleistungen,
  • das Marketing-Konzept,
  • das Supply-Chain-Konzept (Materialflüsse in-bound und out-bound) oder
  • die benötigten Produktionstechnologie und -technik.


Wenn aber die verbreiteten Fehler bei Entscheidungen unter Unsicherheit ab morgen nach dem Kanban-Prinzip gemacht werden, ersetzen Sie lediglich die bisherigen Probleme durch andere. 

Mit der Anzahl der Produktschichten und Entwicklungsstränge steigt der Abstimmungsbedarf. Oft macht es Sinn, in verschiedenen Entwicklungssträngen verschiedene Projektmanagement-Werkzeuge einzusetzen: Die technische Entwicklung setzt Scrum ein, Supply-Chain und Marketing-Entwicklung profitieren von Kanban, die Designentwicklung funktioniert organisationsbedingt nur mit Adhoc-kratie – als Beispiel.

Dabei ist zu klären, wie und wann Koordination und Integration stattfinden: z. B. in festen Zyklen, wenn ein Projektstrang einen Meilenstein erreicht hat, wenn alle betroffenen Stränge fertig sind … . Alles Fragen, die sich bei Softwareprojekten kaum stellen.

Es handelt sich dabei nicht um Argumente, nicht auf Agilität zu setzen. Ganz im Gegenteil: je komplexer das Projekt, umso mehr kann es durch agile bottom-up Koordination profitieren. Es geht nur darum, dass agile Werkzeuge differenzierter und “stärker adaptiert” zum Einsatz kommen sollten, als im Standard-Softwareprojekt.

Erforderliche Anpassungen

Die stetige Verbreitung des agilen Projektmanagements außerhalb der Softwareentwicklung zeigt, daß Agilität und auch Scrum auch dort funktionieren. Als dritter Weg zwischen linearer top-down Planung und der Adhokratie löst Agilität die jeweiligen Probleme der beiden anderen Wege.

Allerdings kann die Einführung von agilem Projektmanagement auch scheitern. Dies geschieht regelmäßig, wenn agile Methoden oder Prinzipien per Gebrauchsanleitung implementiert werden. 

Zum Beispiel wurde in der Entwicklungsabteilung eines Automotive-Zulieferers SCRUM eingeführt. Die Mitarbeiter (m/w) wurden trainiert. Scrum-Master und Product-Owner wurden ausgewählt und in ihre Rollen eingewiesen. Bei der Erstellung des Product-Backlogs wurde es schon schwierig … und mit Beginn der Sprints setzte komplette Konfusion ein.

Später stellte sich heraus, dass ein Product-Backlog in Form von User-Stories und die Entwicklung in Iterationen für die Projektaufgabe absolut unpassend waren. 

Ein neuer Berater erkannte das Problem. Er half dem Entwicklungsteam, es zu verstehen und einzuordnen. Gemeinsam wurden die agilen Werkzeuge angepasst – worauf sich die erhofften Resultate endlich einstellten.

SolidCreativity's Pascal Jarry zu den agilen Anfängen

Die agile Produktentwicklung wurde nicht am grünen Tisch entwickelt. Sie ist die Formalisierung von Praktiken, die in den achtziger Jahren bei sich selbst organisierenden Teams beobachtet wurde. 

Pascal Jarry ist einer der Pioniere, die das Potential der agilen Methoden für die industrielle Produktentwicklung entdeckte. Zuvor leitete er zwanzig Jahre lang auf drei Kontinenten die Entwicklung von Videospielen. 

Er erinnert sich: “Auf internationalen Konferenzen der Videospieleindustrie tauschten wir Entwicklungsleiter uns aus. Alle hatten dasselbe Problem: unsere Entwicklungsteams waren immer größer geworden. Wir versuchten, die Methoden zu professionalisieren und die Teams verloren dabei ihre Kreativität, ihre Motivation und ihre Effektivität.

Die gängigen Methoden verlangten nach mehr Disziplin und Kontrolle. Leider an den falschen Stellen. Wir waren dabei, das System bürokratisch gegen die Wand zu fahren. Wir tauschten unsere Erfahrungen und “best practices” aus. Dann experimentierten wir mit den Methoden und trafen uns wieder zum Abgleich. Es wurden Veröffentlichungen geschrieben, dann Bücher. Wir probierten aus, und wir passten an. Wir waren ohnehin agil – aber in diesem Prozess wurden wir “Agile”.

Die Prinzipien und Werkzeuge der Agilität etablierten sich also in der Softwareentwicklung. Ab 2004, mit meinem eigenen Unternehmen, machte ich diese Werkzeuge allen entwickelnden und innovierenden Organisationen zugänglich, mit dem Fokus auf non-IT Projekte.”