Jedes Projekt ist anders "anders" Agil, hybrid, traditionell? Pragmatisch!

Agil, hybrid, traditionell? Pragmatisch!

Dogmatismus schadet der Agilität. Es gibt kein "richtiges" Scrum, sondern nur für das Team und das Projekt passende Vorgehensweisen. Matthias Eberspächer plädiert für Pragmatismus beim "Maßschneidern" der Vorgehensweise (mit Audio-Datei!).

Management Summary

Jedes Projekt ist anders "anders" Agil, hybrid, traditionell? Pragmatisch!

Agil, hybrid, traditionell? Pragmatisch!

Dogmatismus schadet der Agilität. Es gibt kein "richtiges" Scrum, sondern nur für das Team und das Projekt passende Vorgehensweisen. Matthias Eberspächer plädiert für Pragmatismus beim "Maßschneidern" der Vorgehensweise (mit Audio-Datei!).

Management Summary

Wir empfehlen zum Thema Hybrides Projektmanagement
5 Tage
12.09.2024
1,395,-
Hybrides Projektmanagement - das Beste aus 2 Welten vereinen

Lernen Sie das Wichtigste beim Einsatz von hybridem Projektmanagement, damit auch Sie in Ihrem Unternehmen das Beste aus zwei Welten kombinieren. Mehr Infos

Kurz nach der Jahrtausendwende hatte ich ein mäßig erfolgreiches Software-Entwicklungsprojekt übernommen und überlegte, mit welchen organisatorischen Änderungen das Projekt zu sanieren sei. Der damalige Software-Architekt des Projekts sagte mir, dass man so wie in diesem Projekt keine Software mehr entwickeln würde, heutzutage mache man das nach Scrum!

Scrum – was ist das?

Davon hatte ich vorher noch nie gehört, also machte ich mich auf die Suche nach Artikeln und Büchern, um meine Wissenslücke zu schließen. Ich fand dazu jedoch fast nichts! Es gab lediglich ein paar Bücher, in denen die Ideen hinter Scrum beschrieben waren. Diese waren aber recht akademisch und mit sehr wenig praktischen Erfahrungen hinterlegt. Daneben gab es zahlreiche Erfahrungsberichte im Internet, in denen verschiedene Projektteams "ihr Scrum" beschrieben. Diese experimentierten mit sehr unterschiedlichen agilen und nicht-agilen Konzepten: verschiedene feste Sprintlängen, variable und konvergierende Sprintlängen, Rollentausch, verschiedene Teamgrößen, Kombination von agilen Konzept-, Entwicklungs- und Test-Teams usw.

In wohlwollender Erinnerung blieb mir der "Literatur-Freitag", den eines dieser Teams beschrieb: Freitagnachmittags war es den Teammitgliedern freigestellt, ein Buch oder eine Zeitschrift mitzubringen, zu lesen und über das Gelesene mit den anderen zu diskutieren. Es gab keine Vorgabe, welche Art von Literatur das sein sollte. Am Anfang dominierte Unterhaltungsliteratur. Mit der Zeit wurde der Literatur-Freitag aber immer mehr zur persönlichen Fortbildung benutzt, bis das Team schließlich selbstständig (!) eine "Leseliste" mit für das Projekt relevanten Artikeln und Büchern erstellte, über die es dann vom jeweiligen Leser Vorträge gab. Irgendwie schade, dass dieses "agile Konzept" nicht überlebt hat!

Jeder hatte sein "eigenes Scrum"

Einerseits war diese unspezifische Ansammlung höchst verschiedener Erfahrungen für mich auf der Suche nach Wahrheit und Sicherheit nicht wirklich hilfreich, andererseits war alles sehr offen, frei und flexibel. Es gab fast keine Regeln und die beschriebenen Scrum-Modelle unterschieden sich sehr. Eine Botschaft hatten aber fast alle diese Erfahrungsberichte gemeinsam:

"Das hier ist unser Scrum. Wir haben es so lange angepasst, bis es für uns richtig war. Andere Teams müssen ihr eigenes Scrum finden, also das, was für ihre jeweilige Aufgabe und ihr Team am besten passt. Macht euer eigenes Ding! Macht, was für euch passt! Macht es einfach!"

Auch mein Team und ich fanden zu unserem "eigenen Scrum". Dazu aber später.

Der Aufstieg der "agilen Evangelisten"

Mittlerweile gibt es seit einigen Jahren festgeschriebene, agile Vorgehensmodelle. Diese entstanden auf Basis des Agilen Manifests (Beck et al., 2001). Das Agile Manifest selbst ist noch kein Vorgehensmodell. Darauf weist auch Timm Richter in seinem Beitrag "Bringen wir Agilität wieder ins Gleichgewicht" hin, in dem er sich ausführlich mit den unterschiedlichen Interpretationen des Agilen Manifests auseinandersetzt (Richter, 2020).

Das Agile Manifest ist vielmehr ein Wertekanon von Leitsätzen, aus denen sich zwölf Prinzipien (Beck et al., 2001, Menüpunkt "Twelve Principles of Agile Software") für die agile Arbeit ableiten. Sie schreiben weder ein bestimmtes Vorgehen, noch Rollen, noch Artefakte vor. Auf Basis des Agilen Manifests entstanden in den Millenium-Jahren erste agile Vorgehensmodelle, z.B. 2010 der erste Scrum Guide von Ken Schwaber und Jeff Sutherland. (Schwaber und Sutherland, 2017).

Dann kamen die "agilen Evangelisten" – eine selbst gewählte Bezeichnung von Verfechtern agiler Organisationsformen. So bietet z.B. Mountain Goat Software ein "Agile Training for Agile Evangelists" an (Mountain Goat Software, 2020). Führen wir die Evangelisten-Metapher fort: Auf Basis der neuen "Glaubensgrundsätze" und der Erfahrungen der ersten Scrum-Teams entstanden neue "Kirchen" wie Scrum.org oder Scrum Alliance.

Hinzu kamen zahlreiche weitere Zertifizierungs-Anbieter: Neben den etablierten Verbänden wie PMI, IPMA und AXELOS bieten auch Veteranen der Agilität wie Boris Gloger eigene Zertifizierungen an. Sogar beim TÜV kann man sich zum Scrum Master zertifizieren lassen! Auch erste große Unternehmen "agilisierten" bereits ihre bestehenden, traditionellen Projektvorgehensmodelle.

Nun kann man weder einen allgemeinen Wertekanon noch die Suche nach dem "eigenen Scrum" zertifizieren. Dafür braucht es schon überprüfbare Kenntnisse, was "richtiges" Scrum denn nun ist. Die Anhänger der jeweiligen "Kirchen" vertreten diese Festlegungen (z.B.: "Der Product Owner muss aus der Kundenorganisation kommen") heute zum Teil sehr fanatisch: Ich habe es selbst erlebt, dass ein Berater seinen Auftrag abbrach, weil die Organisation zwar Scrum einführen wollte, aber eben nicht "richtig".

Geht ohne agile Transformation gar nichts mehr?

Die vorherrschende Meinung dieser Evangelisten ist heute, dass man nur "ganzheitlich" agil sein kann, oder eben gar nicht. Am besten muss zuerst die gesamte Organisation agil transformiert werden, danach kann man an agile Projekte denken. Einsatz nur einzelner agiler Konzepte ist verpönt und wird belächelt oder mit fehlendem Mut zu "echter" Agilität abgetan.

Das könnte Sie auch interessieren

Vorschaubild

Die agile Transition sollte ein großes, traditionelles IT-Unternehmen leistungsfähiger machen. Stattdessen sank die Produktivität. Grund dafür waren vier Kardinalfehler: z.B.

Vorschaubild

Am Anfang des agilen Arbeitens herrscht oft sprachliche Verwirrung – kein Wunder bei der Vielzahl an Frameworks mit jeweils eigenen Praktiken, Prinzipien und Werten.

Vorschaubild
Teil 1:
Die drei größten Fehler bei der Einführung von Agile

Der Hype um Agile hat auch Schattenseiten, u.a.: halbherzige und wenig durchdachte Einführungen agiler Methoden oder Vorgehensweisen. Franziska Gütle stellt zunächst die drei größten Fehler bei der agilen Transformation vor und verdeutlicht …

Vorschaubild

Lebt Ihr Team bereits Agilität? Carsten Rasche und Moritz Müller stellen Ihnen sieben Verhaltensweisen vor, an denen Sie dies erkennen und geben Tipps, wie Sie Ihr Team beim Aufbau eines agilen Mindsets unterstützen.

Alle Kommentare (12)

Silke
Kentschke

Genau so muss man agile / hypride Projektarbeit angehen. Immer angepasst an das jeweilige Team und an die jeweilige Aufgabe. Und auch während der Projektlaufzeit kann man reagieren und Scrum-Elemente verändern. Ich bin Scrum Master und handhabe das seit einigen ahren so auch in der Mechanischen Produktentwicklung mit den Entwicklungsteams.
Sehr guter Artikel, den sich andere zu Herzen nehmen sollten!

Rainer
Lingmann

Zu dem Artikel fällt mir so viel ein, dass es ein eigener Artikel würde. Ich beschränke mich mal auf die wichtigsten Punkte.

1. Ich bin dabei, dass Dogmatismus schädlich sein kann und meist falsch ist. Andererseits erlebe ich in der Praxis sehr oft, dass gerade diejenigen Vorgaben von Methoden missachtet oder angepasst werden, die eine echte Veränderung in der Arbeitsweise verursachen würden - also besonders wirkungsvoll wären. Wenn man in solchen Fällen darauf hinweist, dass diese missachtete Vorgabe besser befolgt werden sollte, wird man gerne mal als Dogmatiker beschimpft.

"Dogmatiker" ist nämlich auch der Kampfbegriff derjenigen, die jede Veränderungen vermeiden wollen. Craig Larman hat wunderbar beschrieben, wie das funktioniert: https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Org…

2. "Unseren Scrum" gibt es nicht. Man muss nichts von Scrum machen, man kann alles anders machen und damit erfolgreich sein. Aber es ist dann nicht mehr Scrum. Der Scrum Guide ist eindeutig: "Scrum exists only in its entirety". Was mich wundert ist: Warum wollen so viele Menschen von Scrum abweichen, es dann aber dennoch Scrum nennen? Nennen Sie es doch einfach "unser agiles (oder hybrides) Vorgehen". Aber nein, es heißt dann "unser Scrum", und wenn es nicht funktioniert, dann "funktioniert Scrum nicht". Die eigenen Anpassungen können ja schließlich unmöglich zum Misserfolg beigetragen haben... (siehe Punkt 1)

3. Wirklich schmunzeln musste ich bei dem Satz "Kein Unternehmer würde doch Geld ausgeben, ohne dafür einen Gegenwert zu bekommen." Wenn ich sehe, was Unternehmer alles machen und dafür viel Geld ausgeben, ohne auch nur zu überprüfen, ob sie dafür einen angemessenen Gegenwert bekommen, kann ich dieses Argument einfach nicht ernst nehmen. Warum sollte eigentlich irgendein Unternehmen jemals pleite gehen, wenn Unternehmer ja nur Dinge tun, für die sie einen Gegenwert bekommen? Weil Unternehmer eben manchmal doch den größten Unfug machen.

Hallo Herr Lingmann,

vielen Dank für Ihren Kommentar, ich freue mich auf Ihren Artikel, ich bin mir sicher, auch das Projektmagazin ist an Ihren Erfahrungen interessiert!

Zu ihren Anmerkungen:
1. Als "Dogmatiker" würde ich jemanden bezeichnen, der mir den Mehrwert einer Maßnahme nicht verständlich machen kann und sie einzig damit begründet, dass das halt so zum Vorgehensmodell gehört. Das gilt für "Wasserfallisten" ebenso wie für Agilisten. Natürlich gibt es Organisationen, die erst im Verlauf des Change-Prozesses feststellen, worauf sie sich da eingelassen haben und nun versuchen die "schlimmsten" Änderungen auszubremsen. Der Beratungsauftrag besteht m.E. aber darin, die Veränderungsbereitschaft über den Nutzen zu motivieren statt Änderungen mit autoritären Mitteln gegen Widerstände durchzusetzen. Ich finde es auch nicht schlimm, wenn man zunächst mit einzelnen agilen Ansätzen beginnt und sich nach und nach weiterentwickelt. Lieber mit kleinen, erfolgreichen Schritten die Herzen der Mitarbeiter gewinnen, als sie mit einem zu ambitionierten großen Sprung nach vorne zu verlieren. Das haben wir damals in "unserem" Scrum auch so gemacht.

2. Richtig, "Unser Scrum" gibt es heute so nicht mehr, zum Zeitpunkt meines ersten Scrum-Projekts gab es aber ausschließlich "Unsere Scrums". Sehr viele davon. Ich hänge nicht an dem Begriff "Scrum" und kann mit "unser agiles Vorgehen" sehr gut leben. Nach meiner Beobachtung ist es aber so, dass viele Teams "Unser Agiles Vorgehen" unbedingt "Scrum" nennen wollen. Damit müssen sie sich dann für Abweichungen vom Scrum-Guide rechtfertigen und setzen sich selbst unter Druck 100% konform zu sein, auch wenn das für ihr eigenes Vorhaben gar nicht hilfreich ist.

3. Ich präzisiere: "Kein Unternehmer gibt Geld aus, ohne dafür einen Gegenwert zu erwarten." Der Gegenwert mag sich nicht materialisieren, aber für jede Investition, die ein Unternehmer tätigt verspricht er sich einen wie auch immer gearteten Mehrwert. Mit größerer Erfahrung und dem Blick von außen mag das individuelle Scheitern in manchen Fällen vorhersehbar sein; wenn es das für die handelnden Personen auch wäre, würden sie aber nicht so handeln. Hier greift wieder meine Auffassung unseres Beratungsauftrags: Wenn die Ausgaben so offensichtlich überflüssig und am Bedarf vorbei sind, dann kann ich das sicher auch überzeugend argumentieren. Wenn ich das nicht kann, dann ist es wohl auch nicht so klar.

...bei klassischer Denke mit Scrum.

Auch ich habe einige Anmerkungen zu dem Artikel. Die Sicht von Rainer Lingmann hat mir gefallen!

1. Den Product Owner gibt es schon verdammt lange - länger als Scrum. Man nennt ihn Produktmanager (PM). Der PM schnitzt eine Roadmap, um ein Produkt über mehrere Versionen immer erfolgreicher in den Markt zu bekommen. Man erkennt sofort eine Analogie zu Sprints... Ein Sprint ist ein Wasserfall von 4 Wochen ;-)

2. Damit kommen wir zu dem eigentlichen Punkt, den das Agile Manifest adressiert: Früher hat der PM die Entwicklungsabteilungen drangsaliert und nicht einbezogen. Oft hat sich der PM nur mit Lastenheften um sich geschmissen und auch Vergessen den Kunden zu fragen. Das macht man durch Scrum eben besser.

3. Es ist deswegen sehr wichtig zu wissen, warum es das Agile Manifest gibt und warum in Scrum die Prozesse so sind, wie sie sind. Nur dann kann man reflektiert abweichen, weil man begründet ermitteln kann, dass es eben auch anders hilft. Tut man das nicht, versteckt man gerne seine bisherige Arbeitsweise hinter der Floskel "es hilft ja" und im "Agilen Manifest steht ja auch rechts was".

4. Richtig problematisch wird es aber, wenn man Scrum macht - oder aber irgendwie macht - ohne zu wissen warum. Es gibt eben unterschiedliche Problemstellungen, die man unterschiedlich (und damit dann auch hybrid) angeht. Die Stacey-Matrix zeigt es sehr anschaulich: Simple, Complicated, Complex.

5. Ein letzter Punkt. Mit einem "Proxy" (Proxy-Product-Owner" simuliert man nichts. Der Einsatz von Proxy wird in der Agilen Welt benutzt, um ein Wissenstransfer zu gewährleisten. Ein Proxy-PO ist ein PO, der eben noch nicht so viel weiß, aber einen wissenderen PO in der Hinterhand hat, der dann von ihm einbezogen wird. Das ist ein sehr wichtiges Modell für alle Rollen, um Inselwissen abzubauen.

Ich beende mit dem Verweis auf meinen Fachartikel zu Hybridem Vorgehen hier im projektmagazin: https://www.projektmagazin.de/artikel/agile-festpreisprojekte-der-praxi…

Das ist bei mir funktionierendes hybrides Projektmanagement ;-)

Viele Grüße
Tassilo Kubitz

Dagmar
Börsch
Dr.

Ihr Artikel hat mir aus der Seele gesprochen. Aus meiner Erfahrung kann ich jeden Gedanken von Ihnen unterschreiben! Danke dafür, Herr Eberspächer, dass Sie die "hybride Welt" so auf den Punkt gebracht haben!

Ich habe mich gefragt, was den "Dogmatismus" auslöst? Wieso wird aus einem Modell, dass Orientierung bieten möchte, ein dogmatisches Vorgehensmodell? Worin liegt der der Nutzen zu dogmatisieren?
Ein paar Fragen zu Hypothesen-Ansätzen:
Vielleicht ist es eine vermeindliche Sicherheit durch ein vorgeschriebenes Prozesskorsett?
Möglicherweise ist zum Lernen einer Vorgehnsweise es erst einmal gut, eine enge Prozessführung zu haben?
Oder ist es mangelnde Erfahrung oder fehlende Souveränität der Projektbeteiligten?
Vielleicht ist auch die noch weitverbreitete tayloristische Arbeitskultur in Organisationen die Grundlage, wo Kontrolle eine wichtige Rolle spielt?
Darüber würde ich gerne eine Diskussion führen.

Im Übrigen hat die Helena-Studie ergeben, dass Software auf der ganzen Welt "hybrid" entwicklet wird. https://helenastudy.wordpress.com/
Das, was Sinn macht, wird in der Realität umgesetzt - ganz pragmatisch!
Die Forscher hat dies überrascht.
Mich nicht!

Hallo Frau Börsch,

vielen Dank für Ihren Kommentar! Auch die jüngste GPM-Studie zeigt, dass "hybrid" die neue Regel ist und nicht die Ausnahme (https://www.gpm-blog.de/agile-ansaetze-erfolgreich-ueberwiegend-hybrid-…). In der Studie wird auch schön zwischen "Agilen Ansätzen" und "Projektmanagement" unterschieden - eigentlich kommt sich beides ja gar nicht in die Quere.

Zu ihren Hypothesen: Ich bekenne offen, wenn ich damals ein "Handbuch zur Umsetzung von Scrum" gefunden hätte, hätte ich mich in meinem Team dafür eingesetzt es buchstabengetreu umzusetzen! Warum? Wenn "Etwas Neues" erfolgreich sein soll, dann muss man es doch auch "richtig" machen. In einen Standard sind doch sicher Jahre an Erfahrung hineingeflossen, warum soll ich dann das Rad neu erfinden?

Eigentlich ist das eine typisch traditionelle Denkweise: Arbeit nach Vorschrift, wenn möglich ohne mitzudenken...

Dagegen lautet der erste agile Wert "Individuen und Interaktionen mehr als Prozesse und Werkzeuge". Das lädt doch ganz klar zum experimentieren ein! Das Herumspielen und herumprobieren mit dem eigenen Projektvorgehen sollte m.E. als Stärke gesehen werden.

Joachim
Pfeffer

Hallo Herr Eberspächer,
ich hatte auch mal diese Einstellung, inzwischen denke ich anders. Vor 10 Jahren bin ich mit Pragmatismus und agilen Ansätzen in der Automobilindustrie und im Maschinenbau aufgebrochen. Scrum mochte ich damals nicht besonders gerne, es schien nur schwer zu passen. Inzwischen bin ich der Meinung, dass Scrum einfach nur so konsequent ist, dass es schmerzt. Scrum ist keine Religion, sondern ein seit 30 Jahren in Millionen Organisationen gereiftes Rahmenwerk. Meine Erfahrung: Alle Punkte in Organisationen, die sich mit Scrum reiben, sind Dysfunktionalitäten in den Organisationen und keine Defizite von Scrum. Scrum ist die schonungsloseste Problemsuchmaschine in Organisationen, die ich kenne.
Beispiel: Die von Ihnen beschrieben Inkompatibilität mit Projekten rührt unter anderem daher, dass Projekte ein denkbar schlechtes Vehikel sind um in einer komlexen Umgebung zu bestehen. Auch bei den erwähnten Aspekten Risikomanagement, Phasen- oder Release-Planung sehe ich keine Probleme mit Scrum, die Diskussion würde jedoch den Rahmen hier sprengen.
Pragmatismus und Hybride Ansätze sind für mich Anzeichen, dass die Organsisationen kein Interesse daran haben sich zu grundlegend verändern und zur Höchstleistung zu kommen. Das finde ich auch nicht schlimm, manche sind in Umgebungen in denen Agilität bisher nicht notwendig ist. Andere möchten schlicht so ähnlich weitermachen wie bisher. Das ist ja auch alles OK. Ich mache auch weniger Sport als ich könnte. Und solange die Wettbewerber ähnlich unterwegs sind, gibt es keine Probleme.

Nur in einem Punkt möchte ich meine persönliche Meinung und Erfahrung noch einmal klar herausstellen:
"Hybride pragmatische Ansätzen" als Übergangszone sind das eine. Auf keinen Fall sind solche Ansätze jedoch der Zielzustand oder gar "das Beste aus zwei Welten" wie es manche nennen, es sei denn, die Organisation ist mit sich selbst zufrieden.

Viele Grüße
Joachim Pfeffer

PS: zur Verortung: Bin weder Fundamentalist noch Missionar. Nur ein Organisationsoptimierer. Und wenn ich was besseres als Scrum finde, bin ich offen. ;)

Hallo, da Projekte per definitionem einmalige Vorhaben sind, ist die Vorstellung, dass ein bestimmtes Vorgehensmodell immer das Optimum ist, eigentlich in sich schon fragwürdig. Ich arbeite regelmäßig in Großprojekten. Dort ist genau ein Product Owner nicht umsetzbar, das notwendige Wissen ist nicht in einer Person vereint. Es gibt mehrere Entwicklungsteams und nicht alle sind hinsichtlich ihrer Arbeitsweise beeinflussbar (weil extern, eventuell Produkthersteller mit ergänzenden Dienstleistungen). Wir haben auch schon Sprints/Iterationen unterschiedlich lang gemacht, um etwa Urlaubszeiten (aber nicht alle auf einmal auf Urlaub) zu berücksichtigen. Und ich kann hier noch x Faktoren nennen, die in jedem Projekt anders ein angepasstes Vorgehen erfordern. Dass ein Ideal immer besser ist als die Realität, macht ja genau den Reiz des Dogmatismus aus; man kann jedes Problem als natürliche Folge des Abweichens von der reinen Lehre erklären. Da nie jemand die "reine Lehre" voll umsetzt, wird der Dogmatiker in seiner Meinung immer weiter bestätigt. Ich habe kürzlich ein Projekt erlitten, in dem ein Dogmatiker eine Vorgehensmodell definiert und dem Projekt aufgezwungen hat. Die Hölle! Wir haben das Ziel trotzdem erreicht, aber es war wie Sackhüpfen mit anspruchsvollen Tempovorgaben.

Ernst
Menet

Winston Royce hat vor 50 Jahren in seinem berühmten Paper 'Managing the Development of Large Software Systems' eine Menge intelligenter Dinge gesagt, unter anderem zur originalen Treppendarstellung OHNE Rücksprünge: "I believe in this concept but the implementation described above is risky and invites failure"!
Und etwas hat er ausdrücklich nicht gesagt: er hat den Begriff 'Waterfall' nie (n-i-e) erwähnt. Den Begriff 'Waterfall' bzw. 'Wasserfall' im Zusammenhang mit Projektmanagement müssen deutlich weniger intelligente Wesen später dazu erfunden haben.
Wie sagt man so schön: Lesen bildet! (Und verstehen noch vel mehr!)

Nach meinem Wissensstand erfolgte die erste Erwähnung des Begriffs „Wasserfall-Modell“ im Beitrag „SOFTWARE REQUIREMENTS: ARE THEY REALLY A PROBLEM?“*1 von T. E. Bell und T. A. Thayer von der TRW Defense and Space Systems Group in Redondo Beach, California. Der Beitrag wurde im Rahmen der 2. International Conference on Software Engineering ’76 (ICSE '76) im Oktober 1976, Seite 61–68 veröffentlicht.

Bell & Thayer schreiben: „The same top-down approach to a series of requirements statements is explained, without the specialized military jargon, in an excellent paper by Royce [5]; he introduced the concept of the "waterfall" of development activities.”

Die Publikation "MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS"*2 von Dr. Winston W. Royce stammt aus dem Jahre 1970.

*1 https://www.semanticscholar.org/paper/Software-requirements%3A-Are-they…
*2 https://leadinganswers.typepad.com/leading_answers/files/original_water…

Dieter
Bertsch

„Mittlerweile gibt es seit einigen Jahren festgeschriebene, agile Vorgehensmodelle. Diese entstanden auf Basis des Agilen Manifests (Beck et al., 2001).“

Nach meinen Kenntnissen basiert das Agile Manifest auf den Erfahrungen, die die Verfasser des Manifests mit ihren neu entwickelten Methodiken (ich verwende hier absichtlich nicht den Begriff „Vorgehensmodelle“ – das sind sie nicht) gemacht haben. Und so wurde mit dem Agilen Manifest der Begriff „Agile“ erstmals hierfür verwendet. Die Methodiken jedoch, die zuvor als „lightweight methods“ bekannt waren, sind bereits früher entstanden (z.B. erste Publikation zu Scrum - noch „SCRUM“ geschrieben - stammt aus 1995; zu XP aus 1999).

Fazit: Das Agile Manifest entstand aus Erfahrungen mit agilen Methoden und nicht umgekehrt.