Das Agile Manifest beschreibt Verhaltensregeln und Werte agiler Entwickler Teams. Seit der Entstehung im Jahr 2001 stellt es die Basis für agiles Projektmanagement dar und ist bekannt unter dem Namen „Manifesto for Agile Software Development von Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas“. Man erreicht das Manifest über den folgenden Link.

Kurze Zeitreise

Anfang 2001 trafen sich vor der Kulisse der Wasatch Mountains in Snowbird, Utah, 17 Personen, um über die Zukunft der Softwareentwicklung zu diskutieren. Die Mitglieder der Gruppe teilten die Enttäuschung über den aktuellen Stand der Dinge, wenn es um die Softwareentwicklung in agilen Teams ging. Zu diesem Zeitpunkt waren Sie sich einig, dass man etwas ändern muss. Lediglich bestand noch keine Einigkeit darüber, was genau und wie genau es aussehen sollte.

Das Problem, so waren sie sich einig, bestand darin, dass die Unternehmen sich so sehr auf die exzessive Planung und Dokumentation ihrer Softwareentwicklungszyklen konzentrierten, dass sie das Wesentliche aus den Augen verloren – die Zufriedenheit der Kunden.

Die Unternehmen rühmten sich zwar mit Unternehmenswerten wie „Exzellenz“ und „Integrität“, aber diese Werte trugen wenig dazu bei, die Menschen – insbesondere die Softwareentwickler – auf einen besseren Weg zu bringen. Das musste sich ändern. Viele der Snowbird 17 hatten bereits Ideen, wie man die neue Ära der Softwareentwicklung einläuten kann. Die Reise in die Berge war die Chance, dies zu diskutieren.

Aus diesem verlängerten Wochenende ging das Agile Manifest mit gerade einmal 68 Wörtern hervor. Dieses kurze und knappe Dokument sollte die Softwareentwicklung für immer beeinflussen. In den zwei Jahrzehnten, die seit der Entstehung vergangen sind, haben unzähligen Einzelpersonen, Teams und Unternehmen (in unterschiedlichem Maße) diese Worte bzw. die nachfolgenden 4 Kernaussagen und 12 Prinzipien übernommen.

Die 4 Kernaussagen

„Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan„

Folglich

Individuen und Interaktionen stehen über Prozessen und Werkzeugen

Funktionierende Software steht über umfassender Dokumentation

Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung

Eingehen auf Veränderung steht über dem Befolgen eines Plans

Die 12 Prinzipien:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.„

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung von wertvoller Software zufrieden zu stellen.

„Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.„

Anforderungsänderungen sind auch spät in der Entwicklung willkommen. Agile Prozesse machen Veränderungen für den Wettbewerbsvorteil des Kunden nutzbar.

„Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.„

Liefern Sie regelmäßig, alle paar Wochen bis alle paar Monate, funktionierende Software, wobei ein kürzerer Zeitrahmen bevorzugt wird.

„Business people and developers must work together daily throughout the project.„

Geschäftsleute (Fachleute) und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.

„Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.„

Bauen Sie Projekte um motivierte Einzelpersonen herum auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie darauf, dass die Arbeit erledigt wird.

„The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.„

Die effizienteste und effektivste Methode der Vermittlung von Informationen an und innerhalb eines Entwicklungsteams ist ein Gespräch von Angesicht zu Angesicht.

„Working software is the primary measure of progress.„

Funktionierende Software ist der primäre Maßstab für den Fortschritt.

„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.„

Agile Prozesse fördern die nachhaltige Entwicklung. Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.

„Continuous attention to technical excellence and good design enhances agility.„

Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.

„Simplicity–the art of maximizing the amount of work not done–is essential.„

Einfachheit – die Kunst, die Menge nicht-getaner Arbeit zu maximieren – ist essenziell.

„The best architectures, requirements, and designs emerge from self-organizing teams.„

Die besten Architekturen, Anforderungen und Designs gehen aus sich selbst organisierenden Teams hervor.

„At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.„

In regelmäßigen Abständen reflektiert das Team darüber, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Und das war’s. Seitdem hat sich die Website des Agilen Manifests, wenn überhaupt, nur minimal verändert. Aber die Welt rund um Agile könnte nicht unterschiedlicher sein.

Die große Debatte

Den Snowbird 17 ist es gelungen, ihre unterschiedlichen Standpunkte unter einigen wenigen Kernpunkten zu vereinen. Doch damit war die Debatte noch nicht beendet. In gewisser Weise hat sich Agile in viel mehr Arbeitsweisen aufgesplittert, als die Visionäre es ursprünglich geplant hatten bzw. erahnen konnten. Es scheint, als ob jeder seine eigene Sichtweise von dem Begriff „Agile“ hat und so auch an der eigenen Suppe kocht.

Heute gibt es SAFe und LeSS. Anwendungen von Agile, die nichts mit Softwareentwicklung zu tun haben, auch wenn es im Manifest zu Beginn heißt: „Wir entdecken bessere Wege, Software zu entwickeln, indem wir es tun und anderen helfen, es zu tun“.

Grundsätzlich kann man sagen, dass Zwei Fragen unmittelbar zusammengehören. Die eine richtet sich auf die Wahl des passenden Frameworks als Tool. Die andere auf die Entwicklung der agilen Kultur im Unternehmen. Beides lässt sich nicht getrennt voneinander betrachten.

Darum sollte man sich gleich zu Beginn die Fragen stellen: Was erwartet man? Was soll am Ende des Tages als Ergebnis stehen? Das Skalierungs-Framework selbst ist letztendlich nur ein methodisches Stützrad, um Organisationen Agilität beizubringen. Aber dazu in einem separaten Beitrag mehr.

Dave West, CEO von Scrum.org, der zu verschiedenen Organisationen reist, um agile Praktiken zu beobachten, nannte in einer Publikation ein Forschungsteam, dass agile Methoden einsetzt, um mit Hilfe von Viren ein Heilmittel für genetische Blindheit zu entwickeln.

In der Tat hat sich agiles Vorgehen außerhalb des Softwarebereichs durchgesetzt. Aber es ist nicht unbedingt das, was die Urheber des Manifests beabsichtigten.

Der agile Industriekomplex

Viele argumentieren, dass „Faux Agile“ und sein böser Zwilling „Dark Agile“, durch die Monetarisierung der agilen Ausbildung und Beratung, die gesamte Situation verschlimmern bzw. verschlimmert haben. Einige gehen sogar so weit, dass sie die Organisationen, die hinter dieser Monetarisierung stehen, als „The Agile Industrial Complex“ bezeichnen.

„Es gibt den agilen Cargo-Kult, bei dem man zwar die richtigen Dinge tut und sagt aber die grundlegenden Prinzipien nicht versteht bzw. schlichtweg nicht einhält. Ich selbst kann dies noch nicht so gut beurteilen, da ich noch nicht so viele agile Teams in Aktion gesehen habe, um eine global repräsentative Aussage zu treffen.

Man kann es nennen, wie man will. Ob „faux“, „dark“ oder „Cargo-Kult“, diese agilen Subversionen führen oft zu Situationen, die den Intentionen des Manifests zuwiderlaufen – Mikromanagement, Burnout-Rate, mangelnde Lieferfähigkeiten und das Festhalten an veralteten Prozessen bzw. Konzepten, statt an Prinzipien, sind die auffälligsten Beispiele. Selbst wenn man in dem Bereich ein Zertifikat erworben hat, führen Erfahrungen wie diese, die man in Zusammenhang mit agilen Methoden hatte, oft dazu, dass manche Menschen agilen Methoden ganz abschwören oder sie so umschreiben, dass sie ihre realen Erfahrungen damit widerspiegeln.

Ron Jeffries, einer der Snowbird 17, hat versucht, diesen Irrwegen mit folgender Einschränkung zu begegnen:

“Here and in other writings, I use the quoted word ‘Agile’ to refer to the many instances, approaches, and processes that use the word ‘agile’ to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to ‘Faux Agile’ for emphasis, or to ‘Dark Agile’, which I use to describe so-called ‘Agile’ approaches that have really gone bad. I might refer to ‘Manifesto Agile’ to mean the core ideas from the Manifesto, in which I still believe.”

„Hier und in anderen Schriften verwende ich das zitierte Wort ‚Agile‘, um mich auf die vielen Instanzen, Ansätze und Prozesse zu beziehen, die das Wort ‚Agile‘ verwenden, um sich selbst zu beschreiben, die aber nicht unbedingt den Buchstaben oder dem Geist der Agilen Softwareentwicklung entsprechen, über die wir im Agilen Manifest geschrieben haben. Ich beziehe mich manchmal auf „Faux Agile“, um dies zu betonen, oder auf „Dark Agile“, womit ich sogenannte „agile“ Ansätze beschreibe, die wirklich schlecht geworden sind. Mit ‚Manifest Agile‘ bezeichne ich die Kernideen des Manifests, an die ich immer noch glaube.“

Jetzt kann man sich natürlich die Frage stellen, ob das Agile Manifest angesichts der weiten und manchmal fehlgeleiteten Verbreitung von Agile immer noch ein Dokument darstellt, auf das man sich beziehen sollte oder ob es nicht schon obsolet ist.

Ist das Manifest noch relevant?

Nun, nachdem ich mich erst seit kurzer Zeit mit dieser Thematik auseinandersetze, mag meine Einschätzung nicht qualifiziert genug sein. Dennoch glaube ich, dass Zeit relativ ist. Und soweit es mir meine Recherchen und unzähligen Gespräche mit Mitstreitern sowie Entwicklerfreunden gestatten, bin ich davon überzeugt, ein recht gutes Bild von der Ist-Situation erhalten zu haben. Die Antwort lautet „Ja!“. Man kann sich meiner Meinung nach immer noch auf das Manifest beziehen!

Fazit

Die zwölf Prinzipien machen deutlich, dass die Anfänge des agilen Projektmanagements von einer Ablehnung traditionellen Projektmanagements mit intensiver Planung, Überwachung und Steuerung geprägt sind.

Das agile Manifest beinhaltet vier Werte und zwölf Prinzipien. Damit ist es keine Checkliste, die man befolgt und abhakt. Vielmehr gilt es, diese Werte und Prinzipien im Team zu etablieren und damit ein agiles Mindset zu entwickeln.

Damit lassen sich meiner Meinung nach komplexe Anwendungen sinnvoll und human, sowohl mit kleinen als auch großen Teams realisieren.