Vor 14 Jahren steckte eine Gruppe von Softwareentwicklern die Köpfe zusammen und entwarf ein Manifest, das die IT-Welt im Sturm erobern sollte. Wir befragten Brian Marick, einen der Co-Autoren des Manifests für Agile Softwareentwicklung, dazu, was von den ursprünglichen Ideen geblieben ist.

Wie sich Dave Thomas einmal erinnerte, begann alles mit einer Gruppe von „17 naiven, weißen Jungs im mittleren Alter“. Getragen von einem gemeinsamen Glauben an Responsivität, die Zusammenarbeit mit dem Kunden und an „bessere Wege, Software zu entwickeln“ schrieben sie das Manifest für Agile Softwareentwicklung, das – zum Besseren oder zum Schlechteren – zu einem der angesagtesten Programmierkonzepte werden sollte, die die IT jemals gesehen hat. Um unser Gedächtnis aufzufrischen:

Wir erschließen bessere Wege, Software zu entwickeln,
indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,
schätzen wir die Werte auf der linken Seite höher ein.

(Aus dem Manifest für Agile Softwareentwicklung)

Die guten Absichten waren da, allerdings klaffte eine Lücke zwischen dem, was das Manifest aussagt und wie agile Praktiken auszusehen haben. Und in dieser Lücke sahen zahllose Unternehmer vor allem eine Frage: Wie kann ich diesen Umstand monetarisieren?

In den vergangenen Monaten waren wir Zeuge einer zunehmende Desillusionierung. Viele einflussreiche Denker stellten die Relevanz oder den „Gesundheitszustand“ von Agile in Frage, wobei einige gar behaupteten, dass der Geschäftswert wichtiger sei als Manifeste.

Obwohl er nichts darüber sagen konnte, wo Agile in 10 Jahren stehen wird, ist der von uns befragte Co-Autor des Manifests für Agile Softwareentwicklung Brian Marick der Ansicht, dass Agile zumindest heute noch relevant ist.

JAXenter: Glaubst du, dass das Manifest für Agile Softwareentwicklung heute genau so gültig ist wie im Jahr 2001?

Brian Marick: Insoweit dass man das „Wir erschließen“ ernst nimmt, ja. Von den vier Werten wird „(wir schätzen) Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ wie ich finde häufig dazu genutzt, Diskussionen über Prozesse und Tools niederzuknüppeln, was schade ist. 2001 hatten Individuen und Interaktionen einen niedrigeren Status inne als Prozesse und Tools. 2015 ist das Gegenteil der Fall – zumindest bei denjenigen, die gut mit Individuen und Interaktionen umgehen können und deshalb in den meisten Organisationen den größten Einfluss haben. Aber wie sich heraus gestellt hat, sind Werkzeuge und (informelle, stillschweigende) Prozesse ziemlich wichtig.

Ärgert es dich, dass der Begriff „Agile“ so locker verwendet wird?

Eine Zeitlang hat es das, aber jetzt nicht mehr. Menschen, die organisatorischen Wandel ernst nehmen, können den Unterschied ziemlich leicht feststellen. Diejenigen, die auf der Suche nach einer schnellen Lösung sind, werden sowieso immer von irgend jemandem geschröpft.

Was glaubst du muss sich in der Agile-Bewegung ändern?

Zu Beginn war Agile eine dieser seltenen Verschmelzungen des Sozialen und des Technischen. Ich habe schon oft Pete McBreen zitiert: “the Agile methodologies are methodologies created by people who like to program”. (Das war zwar nicht ganz richtig, aber diese Leute hatten einen viel größeren Einfluss als in früheren Methodologien.)

Seitdem sind die Programmierer weitgehend von Agile abgerückt. Das hat eine Lücke in der Diskussion aufgerissen. Wie jemand (der gerne anonym bleiben möchte) mir einmal geschrieben hat: “I’ve also been tired for years of software people who seem embarrassed to admit that, at some point in the proceedings, someone competent has to write some damn code.”

Diese Menschen leisten diejenige Arbeit, die eigentlich die Agile-„Bewegung“ leisten sollte, außer an Orten wie sprachspezifischen Schauplätzen (z. B. Ruby), Open Source, oder Software Craftsmanship-Konferenzen. Das, was übrig bleibt, fällt viel zu oft unter generische Management-Lehren wie „ein guter Manager kann alles managen“ und/oder Varianten dessen, was Jerry Weinberg in einem völlig anderen technologischen Umfeld populär gemacht hat (womit ich nicht übereinstimme, da ich nicht glaube, dass Kultur von Technologie unabhängig ist).

Als Folge davon hat Agile, beispielsweise aufgrund seiner Betonung der Face-to-Face-Zusammenarbeit, der stetig steigenden Anzahl von Menschen, die nicht vor Ort, sondern aus der Ferne arbeiten, nicht mehr viel zu sagen (außer vielleicht: „dich sollte es nicht geben“).

(Zur Erinnerung:) Die zwölf Prinzipien der Agilen Softwareentwicklung

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

Heisse Anforderungsänderungen selbst spät
in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen
zum Wettbewerbsvorteil des Kunden.

Liefere funktionierende Software
regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne.

Fachexperten und Entwickler
müssen während des Projektes
täglich zusammenarbeiten.

Errichte Projekte rund um motivierte Individuen.
Gib ihnen das Umfeld und die Unterstützung, die sie benötigen
und vertraue darauf, dass sie die Aufgabe erledigen.

Die effizienteste und effektivste Methode, Informationen
an und innerhalb eines Entwicklungsteams zu übermitteln,
ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software ist das
wichtigste Fortschrittsmaß.

Agile Prozesse fördern nachhaltige Entwicklung.
Die Auftraggeber, Entwickler und Benutzer sollten ein
gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Ständiges Augenmerk auf technische Exzellenz und
gutes Design fördert Agilität.

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

Die besten Architekturen, Anforderungen und Entwürfe
entstehen durch selbstorganisierte Teams.

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

(Via agilemanifesto.org)