Gedankenexperiment: Der wahre Kern der Agilität

Je länger du dich mit Agilität beschäftigst, desto klarer wird dir vermutlich, wie fundamental das agile Manifest und seine zwölf Prinzipien wirklich sind. Wir haben sie in den vorigen Kapiteln besprochen, und auf den ersten Blick klingen sie logisch, sinnvoll und fast schon selbstverständlich.

Aber ich möchte dich nun zu einem Gedankenexperiment einladen. Lass uns tiefer graben und die wahre Absicht hinter dem Manifest hinterfragen. Was ich dir jetzt präsentiere, ist eine bewusst provokante These. Vielleicht wirst du zusammenzucken oder meine Interpretation für falsch halten. Ich bitte dich aber, mir bis zum Ende zu folgen, denn ich glaube, aus diesem Experiment kann eine wertvolle Diskussion entstehen, die unser Verständnis von Agilität schärft.

Die Hypothese

Das agile Manifest entstand, weil die klassische Softwareentwicklung im Wasserfall-Modell oft nicht die erhofften Ergebnisse lieferte. Heute wird Agilität häufig als etwas verstanden, das vor allem gut für die Menschen im Entwicklungsprozess ist – für die Entwickler, die Teams und deren Arbeitsumfeld.

Und jetzt kommt mein Gedankenexperiment: Ich behaupte, das ist nur ein Nebeneffekt. Die Autoren des Manifests wollten nicht in erster Linie ein besseres Arbeitsumfeld für Entwickler schaffen. Ihr primäres Ziel war es, dem Kunden schneller ein gutes und wertvolles Produkt zu liefern.

Schon im ersten agilen Prinzip steht: „Wir erschließen bessere Wege, Software zu entwickeln.“ Es geht um die Software, nicht darum, dass uns das Arbeiten leichter fällt. Die steile These lautet also: Im Kern des agilen Manifests geht es darum, Software besser zu entwickeln, um dem Kunden einen Wettbewerbsvorteil zu verschaffen. Der Mensch im agilen Umfeld und sein Wohlbefinden sind dabei zunächst zweitrangig.

Nimm diese Hypothese für einen Moment an und lass uns schauen, wohin sie uns führt.

Die Geschichte hinter dem Manifest

Um diese Hypothese zu untermauern, müssen wir noch einmal tiefer in die Entstehungsgeschichte des Manifests eintauchen, als wir es in Kapitel 1 getan haben – diesmal aber mit einem scharfen Blick auf den wirtschaftlichen Kontext, in dem es entstand.

Lass uns daher noch einmal aus einer anderen Perspektive in das Jahr 2001 zurückreisen. Das Internet war erwachsen geworden und hatte die Märkte fundamental verändert. Plötzlich hatte jeder Zugang zum globalen Markt, der dadurch extrem transparent und schnelllebig wurde. Für Unternehmen entstand ein enormer Druck. Sie mussten ihre Produkte und Dienstleistungen online präsentieren und viel schneller auf Veränderungen reagieren als je zuvor.

In dieser Zeit arbeiteten die meisten noch nach dem Wasserfall-Prinzip: starre, aufeinanderfolgende Phasen von Anforderung über Konzeption und Entwicklung bis zum Test. Dieser Prozess war schwerfällig und langsam.

Genau in diesem Umfeld trafen sich die 17 Vordenker der Softwareentwicklung – Vertreter von Ansätzen wie Scrum (ja, Scrum ist älter als das agile Manifest) oder Extreme Programming. Sie kannten die Probleme aus der Praxis und suchten nach einem leichtgewichtigeren Ansatz (damals sprachen sie von “Lightweight”, bevor sie sich auf “Agil” einigten). Ihr Ziel war es, keine neuen starren Regeln, sondern Orientierungshilfen – “Guidelines” – zu formulieren.

Ihr Weg zu den vier Kernwerten zeigt ihre Denkweise:

• Sie stellten fest: „Great Teams make great Software“. Daraus entstand der Fokus auf „Individuen und Interaktionen“.
• Sie erkannten: „Prozesse und Tools machen uns langsam“. So wurde die Interaktion wichtiger als Prozesse und Werkzeuge.
• Sie wussten: „Regelmäßiges Liefern von Software bringt dem Kunden viel mehr Wert als Dokumentation“. Das führte zu „Funktionierende Software über umfassende Dokumentation“.
• Sie waren frustriert, dass Diskussionen über Verträge oft die eigentliche Entwicklung blockierten. Ihre Lösung: Der Kunde muss von Anfang an Teil des Projekts sein. Daraus wurde „Zusammenarbeit mit dem Kunden über Vertragsverhandlung“.
• Inspiriert von Extreme Programming fügten sie hinzu, dass man auf äußere Einflüsse reagieren muss, anstatt stur einem Plan zu folgen. Das Ergebnis: „Reagieren auf Veränderungen über das Befolgen eines Plans“.

Agilität als Antwort auf ein Marktproblem

Wenn du dir diese Entstehungsgeschichte im Kontext des boomenden Internets ansiehst, wird eines klar: Das Wasserfall-Modell war für diese neue, schnelle Welt tot. Mit diesem Ansatz konnten Unternehmen am Markt nicht mehr erfolgreich sein.

Das agile Manifest war die Antwort auf ein ökonomisches Problem. Es ging darum, den Kunden in die Lage zu versetzen, in einem hochdynamischen Marktumfeld zu bestehen. Das Produkt, der Kunde und die schnelle Lieferung von werthaltiger Software stehen im absoluten Mittelpunkt.

Der positive Nebeneffekt

Natürlich hat agiles Arbeiten eine extrem positive Auswirkung auf das Arbeitsumfeld. Ein motiviertes Team, das Sinn in seiner Arbeit sieht und dem vertraut wird, leistet bessere Arbeit und entwickelt bessere Software. Das ist unbestreitbar und großartig.

Im Rahmen unseres Gedankenexperiments ist dieses gute Arbeitsumfeld aber nur ein notwendiger Nebeneffekt, nicht das primäre Ziel. Es ist das Mittel zum Zweck, um das eigentliche Ziel zu erreichen: dem Kunden zu helfen, am Markt erfolgreich zu sein.

Was bedeutet das für deine tägliche Arbeit? Der Wert von „Wert“

Wenn du diese Perspektive einnimmst, verändert das deinen Blick auf alltägliche agile Praktiken. Agilität ist kein Selbstzweck. Hinter ihr steckt ein fundamentaler ökonomischer Gedanke.

Der oft benutzte Begriff „Wert“ (Value) wird plötzlich ganz konkret. Es geht nicht um einen abstrakten Wert, sondern in erster Linie um Geld. Entweder verdienst du mit deiner Software Geld für deinen Kunden oder du hilfst ihm, Geld zu sparen, indem du Prozesse optimierst.

Stelle dir mit dieser Brille einmal folgende Fragen:

• Retro: Machen wir eine Retro nur, damit wir als Menschen besser miteinander auskommen? Oder machen wir sie, um Blockaden zu finden, die uns daran hindern, dem Kunden schneller Wert zu liefern? Der Fokus verschiebt sich.
• Refinement: Dient das Refinement dazu, uns die Arbeit möglichst einfach zu machen? Oder dazu, das nächste Inkrement so zu schneiden, dass es mit dem geringsten Aufwand den maximalen ökonomischen Wert für den Kunden erzeugt?
• Eine Story oder ein Inkrement: Wenn du das nächste Feature planst, frage dich: Wie viel Wert in Euro steckt wirklich in dem, was du hier lieferst? Kannst du diesen Wert maximieren, indem du es anders schneidest oder etwas anderes priorisierst?

Jeff Sutherland, einer der Scrum-Erfinder, fasst es so in seinem Buch “Scrum: The Art of Doing Twice the Work in Half the Time”¹ zusammen: „Figure out where the most value can be delivered for the least effort and do that one right away.“ (Finde heraus, wo der meiste Wert mit dem geringsten Aufwand geliefert werden kann, und erledige genau das sofort.)

Dieses Gedankenexperiment soll bewusst schwarz-weiß malen, um eine Diskussion anzustoßen. Aber ich glaube fest daran: Wenn wir verstehen, warum wir agil arbeiten – nämlich um unseren Kunden im Wettbewerb zu helfen –, können wir unsere Methoden und Prinzipien viel gezielter und effektiver einsetzen. Es gibt all unseren agilen Zeremonien einen tieferen, ökonomischen Sinn.

Das Gedankenexperiment hat deutlich gemacht: Im Kern geht es um Wert für den Kunden. Im nächsten Kapitel schauen wir nach vorn – in die Diskussion um „Post-Agile“ und was wirklich dahintersteckt.

Quellen

1. Sutherland, Jeff, und J. J. Sutherland. Scrum: the art of doing twice the work in half the time. Revised and updated edition. Penguin Books, 2024.↩︎