Das Agile Manifest (das eigentlich „Agile ‘Software Development’ Manifesto“ heißt, was später noch relevant werden wird) lautet:

„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.“

Bereits im ersten Satz des Manifests steckt der vollständige Geist des Agilen: Durch ständiges entwickeln von Software, lernen die Entwickler neue Wege kennen, wie das Entwickeln noch besser vonstatten gehen kann – also immer wieder. Nichts ist festgeschrieben. Die Freiheit im Vorgang (oder des Prozesses) ist demnach die Grundlage jeder Entwicklertätigkeit.

Freiheit und Kreativität

Die Nachrangigkeit von Prozessen um ihrerselbst Willen wird sodann im ersten Leitsatz ausformuliert: Individuen und Interaktionen sind wichtiger als Prozesse (und Werkzeuge). Das heißt, dass Prozesse zwar eine gewisse Relevanz haben, aber es darf nicht nur des Prinzips wegen an ihnen festgehalten werden. Ebenso ist nicht ultimativ festzuschreiben, welches Werkzeug zum Erreichen des Ziels genutzt werden soll.

Hierin steckt die Freiheit zum Wohle der Kreativität. Prozesse hingegen ersticken Kreativität und fix vorgeschriebene Mittel erhöhen den Grad der Unfreiheit.

Im gleichen Sinne kann das „Reagieren auf Veränderung“ des vierten Leitsatzes gelesen werden, indem lieber auf (neue) Anforderungen des Kunden (denn ebendort kommen die Veränderungen im Projekt – zumeist – her) reagiert wird, anstatt dem anfangs fixierten (Zeit-)plan stoisch zu folgen.

Bürokratie und Overhead

Auch will Agilität den Anteil an Arbeit reduzieren oder gar ganz vermeiden, der nicht wirklich zum erreichen des inhaltlichen Ziels notwendig ist.

„Funktionierende Software mehr als umfassende Dokumentation“ heißt demnach, dass mehr an der Software, also am eigentlichen Produkt zu arbeiten ist, als am dokumentieren dessen, was getan wurde.

Auch, dass die „Zusammenarbeit mit dem Kunden mehr als (die) Vertragsverhandlung(en)“ wiegen, zielt auf ein Vermeiden von unnötiger Kommunikation auf beiden Seiten der Beteilgten ab: lieber soll „zusammen“ als „gegeneinander“ kommuniziert werden.

Die meisten Unternehmensjuristen, die mit dem Erstellen von Verträgen betraut werden, werden mit diesem Aspekt wohl ihre Schwierigkeiten haben. Denn anstatt vorerst zu klären, welche Leistungen für welche Gegenleistungen erbracht werden sollen, möchten die agilen Softwarentwickler lieber gleich in die Zusammenarbeit gehen. Das ist aus Sicht des Entwicklers verständlich, denn gerade in der Zusammenarbeit wird oftmals erst klar, wie genau die gewünschte Software aussehen soll.

Wir werden auf dieses Spannungsverhältnis gleich zurückkommen.

Grundsätze versus Organisationsform

Die vier genannten Sätze lassen darüber hinaus völlig unterschiedliche Formen der Erstellung von Software zu – auch das ist ein weiterer Aspekt der anfangs genannten Freiheit in der Organisation (also dem WIE) von Softwareerstellung.

Was ist damit gemeint? Nehmen wir SCRUM als Beispiel:

SCRUM ist eine der bekanntesten Organisationsformen agiler Softwareentwicklung. Doch wer SCRUM als statisch und festgeschriebene Form versteht, missachtet den Kern des Agilen. SCRUM selbst nimmt für sich in Anspruch, den agilen Prinzipien zu entsprechen – und öffent sich damit jedweder Modifikation der Organisationsform bzw. jedwedem Vorgehen, bei der individuellen Erstellung von Software.

Zugleich impliziert dies, dass auch SCRUM im Einzelfall modifiziert werden muss – was wiederum zum Aspekt der Freiheit in der Projektabwicklung führt. Eine angemessene Organisationsform kann demnach auch nicht vorab klar definiert werden, schon weil jedes Projekt anders ist. Die Absicht des Agilen ist hierbei, nicht blind in den Erarbeitungsprozess zu starten, sondern erst mittels Kooperation die notwendigen Bedingungen zu erörtern.

Übertragbarkeit auf andere Entwicklungskontexte

Es wurde unlängst deutlich, dass die Produktion von Software der Kontext war, aus dem heraus sich das agile Manifest entwickelt hat. Daher lautet es ja auch: „Agile ‘Software Development’ Manifesto“.

Eine 1:1-Übertragbarkeit der Prinzipien auf andere Kontexte sollte daher wohlüberlegt sein – gerade, wenn man sich für eine konkrete Organisationsform entschieden hat.

Die vier Sätze des Agilen Manifests können dabei noch am ehesten auf viele Bereich übertragen werden. Aber gerade beim Aspekt der Vertragsverhandlungen wird wohl zunächst der Unternehmensanwalt Einwände erheben, wenn einfach lustvoll „drauflos kollaboriert“ wird, anstatt vorab genauestens zu klären, welche Leistungen eigentlich für welche Werte erbracht werden sollen – wie bereits erwähnt.

Noch unbequemer wird es mit einer bestimmten Organisationsform wie etwa SCRUM: Die wöchentliche, evl. auch tägliche Abgleichung der Arbeitsstände und die gegenseitige Information über vorliegende Probleme wird dann schwierig, wenn die Inhalte, die es zu besprechen sind, heikleren Charakter haben:

Über (unpersönliche) Software oder rein technische sowie materielle Herausforderungen lässt sich leicht sprechen. Organisieren Sie aber ein Changemanagement nach agilen Methoden, dann sollten Sie lieber eine gut funktionierende und offene Diskurs- als auch Kommunikationskultur in Ihrem Unternehmen haben, denn sobald es um individuelle und personenbezogene Themen geht, lassen sich die Probleme nicht mehr so leicht in größerer Runde (SCRUM geht bei Entwicklungsteams von bis zu neun Mitgliedern aus) besprechen – erst recht, wenn diese in Rede stehenden Personen auch noch anwesend sind.

Agilität und die tradierte Steuerbarkeit des Unternehmens

Freiheit, Direktheit, offene Produktionsprozesse – diese Charakteristika des Agilen Manifests stehen einer festgeschriebenen Organsitonsform und planvollen Unternehmensführung zumeist entgegen. Das ist das oben bereits erwähnte Spannungsverhältnis, in dem sich die agile Arbeitsweise befindet, wenn sie in etablierte, konventionelle Unternehmensstrukturen übernommen werden soll.

Dieses Moment verstärkt sich, umso weiter sich das Agile von Softwarekontexten entfernt. Zugleich kann Agilität bisher nicht genutzte Potenziale freisetzen, weil es eben Freiheit als Grundmoment proklamiert. Allerdings muss eine Organisation (ein Unternehmen) zugleich bereit sein für:

• eine belastbare Kommunikationskultur,
• eine gelebte Diskursfähigkeit und
• (er)tragbare Unsicherheiten

Das sind die drei wichtigsten Vraussetzungen auf Unternehmensseite, die vorhanden sein müssen, um wirklich agil arbeiten zu können – gerade, wenn es sich um keine Software-nahe Branche handelt und in dem Unternehmen bisher sehr streng nach festgeschriebenen Prozessen gearbeitet wird.

#tldr

Nur, wer nach den Prinzipien des Agilen Manifests arbeitet, arbeitet auch agil.

Scrum ist mehr ein Prozess als ein Prinzip – es kann vor allem als eine Reaktion auf das Prinzip der (regelmäßigen) Reflektion zur Arbeitsweise und dem Ziel der Steigerung nach Effizienz gelesen werden.

Agil zu arbeiten folgt gerade nicht einem feststehenden Organisationsprinzip, sondern sucht dieses immer wieder neu.

Die Übenahme von agilen Methoden in andere Kontexte und Unternehmen ist sehr voraussetzungsvoll.