In den letzten Wochen fiel mir auf, dass wieder einmal relativ viele Artikel von Fachexperten und bloggenden Softwareentwicklern aufgetaucht sind, die sich grundsätzlich mit dem Thema Agilität und dessen Status Quo auseinandersetzen. So berichtet beispielsweise Eberhard Wolff (@ewolff) in seinem Blog Continuous Architecture bei heise Developer unter dem Titel „Das Problem mit der Agilität“ über seine Erfahrungen mit agilen Transformationen in Projekten und welche Hindernisse er dabei identifiziert hat. Auf der Konferenz JAX 2018 wurde zu dem Thema auch meine oose-Kollegin Kim Duggen interviewt. Ihr Resümee: Ein wesentlicher Erfolgsfaktor für eine erfolgreiche agile Transformation ist ein positives Menschenbild und ein echtes Verinnerlichen und Leben der agilen Werte.

Über Agilität, oder manchmal auch „Agile“ (Warum man letzteren Begriff lieber vermeiden sollte, dazu später mehr), sind gefühlt wohl schon Tausende von Büchern, Fachartikel oder Blogbeiträge geschrieben und veröffentlicht worden. Auf unzähligen Konferenzen wurde das Thema von A bis Z durchgekaut. Agilität, so sollte man glauben, müsste doch schon längst im sogenannten „mainstream“ angekommen sein. Daher sollte man annehmen, dass es zu diesem Thema eigentlich nicht mehr viel Grundsätzliches zu sagen gibt, sondern nur noch konkrete Detailprobleme diskutiert werden müssen. Und eigentlich sollte es auch so sein, dass sich mittlerweile eine weitgehend einheitliche Vorstellung darüber entwickelt und etabliert hat, was unter Agilität zu verstehen ist, und natürlich auch darüber was es definitiv nicht ist.

Doch weit gefehlt!

Nur wenige kennen das Agile Manifest

Das legendäre Agile Manifest aus dem Jahr 2001, also jene von 17 namhaften Softwareentwicklern im Snowbird Ski Resort  (Utah, USA) formulierte Grundsatzerklärung die die Quintessenz agiler Softwareentwicklung festhält, ist mittlerweile rund 17 Jahre alt. Diese kleine Gruppe von Entwicklern (u.a. Kent Beck, Martin Fowler, Robert C. Martin, Jeff Sutherland, Alistair Cockburn, …) kam dort zusammen, um vor dem Hintergrund vieler schlecht laufender Softwareentwicklungsprojekte einmal über Möglichkeiten zu diskutieren, wie man Softwareentwicklung besser machen kann und wie man die häufig gestörten Beziehungen zwischen Entwicklern und Kunden verbessert. Das aus vier Leitsätzen und 12 Prinzipien bestehende Manifest war sowohl ein genereller Aufruf zur Veränderung, sowie vor allem aber auch ein Appell an alle Mitglieder von Entwicklungsorganisationen ihr eigenes Denken und Handeln kritisch zu hinterfragen und zu ändern; d.h. es transportiert so etwas wie ein Mindset, also eine Mentalität und Grundhaltung.

Gelegentlich frage ich in meinen Trainings, oder auch das Auditorium bei meinen Konferenzvorträgen, wer denn das Agile Manifest kennt oder zumindest schon mal davon gehört hat. Das überraschende Ergebnis: Nicht selten melden sich gerade einmal 10% oder weniger der Teilnehmer auf diese Frage. Und das, obwohl mittlerweile sehr viel mehr (ca. 70 – 80%) die Hand heben, wenn ich frage, wer denn in seiner Organisation Scrum einsetzt.

In den Gesprächen im kleineren Kreis in den Seminarpausen oder am Rande der Konferenzen werden solche Aussagen dann auch wieder relativiert. Da heißt es dann häufig: „Ja, also, ehrlich gesagt machen wir ja eher so etwas ähnliches wie Scrum”, oder es wird eingeräumt, dass man sich nur ein paar Werkzeuge aus dem Scrum-Framework herausgepickt hat, aber „…die Retrospektiven machen wir nicht mehr. Die haben irgendwie nichts gebracht.”

Mythen und Missverständnisse

Auch geistern immer noch die abenteuerlichsten Sagen, Mythen und Missverständnisse über Agilität herum.

Die einen sagen, das wäre ja alles lediglich alter Wein in neuen Schläuchen, denn man habe ja auch schon vor Jahrzehnten so gearbeitet, man habe es damals nur nicht Agilität oder „Agile“ genannt. Als vermeintliche Beweise für diese Behauptung werden dann häufig irgendwelche Elemente aus dem agilen Produktentwicklungs-Framework Scrum ins Feld geführt, die man ja so, oder in ähnlicher Form, immer schon praktiziert habe. Einige Beispiele:

  • Potentially Shipable Product-Increment?! — Ja, ja, ist doch nichts Neues. Prototypen haben wir auch damals schon gelegentlich gebaut.
  • Daily Standup Meeting?! — Ein alter Hut! Natürlich haben wir in der Entwicklung auch früher schon häufig miteinander geredet; anders geht das doch gar nicht!
  • Retrospektiven?! — Ach, die haben wir früher Lessons-Learned-Meeting genannt und nach jedem problematischen Projekt durchgeführt.
  • Product Owner?! — Das ist doch letztendlich dasselbe wie ein Projekt-Manager, oder etwa nicht?

Ja, die Idee, iterativ-inkrementell vorzugehen ist alles andere als neu. Bei der NASA hat man das schon sehr früh praktiziert, u.a. im Projekt Mercury (1958 bis 1963) oder bei der Entwicklung der Space-Shuttle-Software. Doch ist das schon agil?

Andere wiederum lesen ein Buch über Scrum und probieren das, was sie gelesen haben, dann einfach mal in ihrer Entwicklung aus, ohne die Hilfe von externen Trainern und Coaches in Anspruch zu nehmen. Dieser „Heimwerker-Ansatz“ (engl. Homegrown Scrum) kann sogar sehr gut funktionieren. Einige der besten und erfolgreichsten Scrum-Teams haben genau so angefangen. Leider gibt es aber auch mindestens genau so viele, oder eher sogar noch mehr Beispiele, bei denen Homegrown Scrum in einer Katastrophe endete. Scrum hört sich sehr leichtgewichtig und einfach umsetzbar an, doch dieser Eindruck täuscht. Tatsächlich ist der erfolgreiche Einsatz von Scrum von sehr vielen Einflussfaktoren abhängig. Insbesondere muss gut verstanden werden, dass ein Kulturwandel eine essenzielle Grundlage ist. Leider heißt es nach einem Scheitern häufig: „Ach, geh weg…agil…das funktioniert doch überhaupt gar nicht!”

Auch Softwareentwickler sind genervt

Auch vielen Softwareentwicklern geht das Thema Agilität mittlerweile massiv auf den Geist. Dabei sticht bei diesen Kritiken häufig hervor, dass die Entwickler gar nicht so sehr die ursprüngliche Idee verteufeln – im Gegenteil –, sondern vielmehr die schlechten konkreten Umsetzungen und gegenwärtigen Ausprägungen in vielen Entwicklungsorganisationen. Zum Ausdruck kommt diese Kritik beispielsweise in der satirischen und polarisierenden Replik Manifesto for Half-Arsed Agile Software Development.

safe-rup
Credit: @PiotrWegert

So beschweren sich Entwickler beispielsweise über Manager mit einem ausgeprägten „Command-and-Control-Gen“, die alles ganz genau überwachen, ständig dazwischen grätschen und die Teams nicht in Ruhe arbeiten lassen. Sie kritisieren, dass das Management unter dem Etikett „Agil“ versucht, eher den Druck zu erhöhen um noch mehr aus ihren Mitarbeitern herauszuquetschen. Oder sie beklagen, dass trotz eines iterativ-inkrementellen Vorgehens mit 2 – 3 wöchigen Sprints am Ende vieler Sprints kein gut funktionierendes, qualitativ hochwertiges Produkt-Inkrement entstanden ist, sondern vielmehr ein mit der heißen Nadel zusammengebastelter Prototyp in zweifelhafter Qualität. Und auch von einer engen Einbindung des Kunden in die Entwicklung sind viele vermeintlich agile Teams weit entfernt. Daher ist es auch überhaupt gar nicht überraschend, dass nach einer Schnellumfrage von JAXenter im Februar 2016 46% der Entwickler der Aussage zustimmten: „Wir nennen zwar vieles agil – wirklich agil ist es aber nicht“.

Und dann ist da ja noch dieser unsägliche Trend, dass ja von jetzt auf gleich die ganze Organisation agil werden muss (was immer auch darunter zu verstehen ist), weil das Top-Level-Management das aus irgendeinem Grund für eine gute Idee hält. Welches Problem damit adressiert werden soll, und welche Verbesserungen sich das Management davon konkret erhofft, und vor allem warum ausgerechnet Agilität jetzt die dazu passende Lösung sein soll, das wird meistens nicht kommuniziert. Von einer echten Einbindung der Mitarbeiter in diesen organisatorischen Entwicklungs- und Veränderungsprozess ganz zu schweigen; es wird einfach beschlossen. Ganz gruselig wird es zumeist dann wenn anschließend dem ganzen Unternehmen top-down ein großes „agiles Skalierungs-Framework“ übergestülpt wird.

Ist Agilität tot?

Und so mehren sich auch mittlerweile die Stimmen, die sagen, dass Agilität quasi tot sei. Unter ihnen befinden sich sogar einige der 17 Erstunterzeichner des Agilen Manifests, wie beispielsweise David Thomas und Andrew Hunt, Autoren des bekannten Buchs „The Pragmatic Programmer – From Journeyman To Master“. In seinem Blogbeitrag „The Failure of Agile“ schreibt Andrew Hunt (Übersetzung aus dem Englischen von mir):

„Das Wort ‚agil‘ ist zu einem Slogan geworden, bestenfalls bedeutungslos, im schlimmsten Fall hurra-patriotisch. Wir haben massenweise Leute, die eine kraftlose Form von ‚agil‘ praktizieren, einen halbherzigen Versuch ein paar ausgewählte Softwareentwicklungspraktiken in schlechter Art und Weise anzuwenden. Wir haben viele agile Fanatiker – im Sinne der Definition, dass ein Fanatiker jemand ist, der seine Anstrengungen verdoppelt, nachdem er sein ursprüngliches Ziel aus den Augen verloren hat.

Und das Schlimmste ist, dass agile Methoden selbst nicht agil waren.”

Und Dave Thomas schreibt in seinem Blogartikel „Agile is Dead (Long Live Agility)“ (Übersetzung aus dem Englischen von mir):

„Nachdem das Manifest populär wurde, wurde das Wort ‚agil‘ zu einem Magneten für jeden, der dabei unterstützen, Stunden abrechnen oder Produkte verkaufen wollte. Es wurde zu einem Marketing-Begriff, der den Verkauf auf die gleiche Weise ankurbeln sollte wie Begriffe wie ‚Öko‘ und ‚Natürlich‘. Ein Wort, das auf dieser Art und Weise missbraucht wird, wird nutzlos – es verliert seine Bedeutung, wenn es in eine Marke übergeht.”

Dave Thomas plädiert außerdem dafür, den Begriff „Agile“ zu streichen, weil sich dieser sehr leicht wie ein Marketing-Etikett überall draufkleben ließe („Agile Team“, „Agile Coach“, „Agile Company“, etc.). „Agile“ ist kein Substantiv, es ist ein Adjektiv, und es muss etwas anderes qualifizieren. Dazu Thomas:

„’Do Agile Right‘ is like saying ‚Do Orange Right.’”

Er empfiehlt, dass wir das Wort „agil“ doch lieber den Leuten überlassen sollten, die nichts tun. Stattdessen sollten wir einen Begriff verwenden, der beschreibt, was wir tun: Agility (Agilität). Es gibt keine „Agile Developer“, sondern es gibt Entwickler, die durch Agilität besser programmieren. Du arbeitest nicht in einem „Agile Team“, sondern Dein Team zeigt Agilität. Und es gibt auch keine „Agile Tools“, sondern es gibt Werkzeuge, die die Agilität des Teams unterstützen und verbessern können.

Software Craftsmanship – Agilität, wie es gemeint war

Einen besonders bemerkenswerten Blogbeitrag zur Debatte lieferte der US-amerikanische Softwareentwickler, Autor und Konferenzsprecher Robert C. Martin, der ebenfalls zu den 17 Erstunterzeichnern des Agilen Manifests gehört. Er bezieht sich in dem Artikel auf Martin Fowlers Keynote-Vortrag auf der Agile Australia 2018 mit dem Titel „The State of Agile in 2018„. In einem fiktiven Dialog zwischen zwei Personen macht Martin deutlich, dass die Software-Craftsmanship-Bewegung (Craftsmanship, dt.: Handwerkskunst oder Kunsthandwerk), die etwa 2009 entstanden ist, eigentlich genau das repräsentiert, was die ursprüngliche Intention von Agilität gewesen war:

„The Agile movement was started by programmers, and software professionals, who held the ideals of Craftsmanship dear. But then the project managers rushed in and said: ‚Wow! Agile is a cool new variation on how to manage projects.‘ […] Craftsmanship is not about new stuff. Craftsmanship is about old stuff. […] It’s about the goal that Kent Beck had for Agile.”

Obwohl die agile Bewegung ursprünglich von Softwareentwicklern initiiert worden war, wird das Thema heutzutage von Projektmanagern, Beratern, Zertifizierungsanbietern, Coaches die keine bis wenig Programmierkenntnisse haben, sowie anderen Nicht-Softwareentwicklern dominiert.

software-craftsmanship-manifesto
Das Manifesto for Software Craftsmanship ergänzt das agile Manifest um Dinge, die vor allem Softwareentwicklern wichtig sind
Und so dürfte es auch nicht überraschen, dass auf entsprechenden Konferenzen zum Thema Agilität die dort anwesenden Entwickler auch mit der Lupe gesucht werden können. Leidenschaftliche Software Craftspeople sehen sich zunehmend eher den Werten, Prinzipien und Tugenden guter Handwerksarbeit verschrieben, lernen und üben ihre Profession, wollen eine partnerschaftliche Zusammenarbeit mit dem Kunden, geben ihr Wissen gerne weiter, haben sich dem lebenslangen Lernen verschrieben, und bilden eine für Jeden offen stehende Gemeinschaft aus Experten. Aus dem Manifesto for Software Craftsmanship geht sehr deutlich hervor, dass das Ziel dieser Bewegung darin besteht, die Botschaft, die einst das Agile Manifest ausgesendet hat, fortzusetzen und weiter zu entwickeln; zu erweitern.

Bleibt also die finale Frage, was jetzt zu tun ist – Agilität begraben?

Back to the roots

Schauen wir noch einmal zurück, warum die 17 Softwareentwickler (Ja, das waren Entwickler, keine Projektleiter!) damals in Snowbird diesen Aufruf zur Veränderung formuliert haben.

Bis etwa zum Ende der 1970er Jahre war Software Engineering eine Disziplin, die sich stark an den Rahmenbedingungen des damals noch vorherrschenden Industriezeitalters orientiert hat. Die industrielle Massenproduktion dominierte noch, und die Arbeitsweise vieler Unternehmen orientierte sich weitgehend noch nach einer Lehre, deren Grundlagen im Jahr 1911 vom US-amerikanischen Maschinenbau-Ingenieur Frederick Winslow Taylor („The Principles of Scientific Management“) beschrieben wurde. Die Märkte waren noch nicht so dynamisch, die Komplexität der Entwicklungsprojekte hielt sich noch in Grenzen, und die Globalisierung war noch nicht so weit fortgeschritten. In der Blütezeit der industriellen Massenproduktion hat der Taylorismus, also die Trennung des denkenden und planenden Managements von den ausführenden Arbeitern, in vielen Branchen relativ gut funktioniert.

Mit dem Übergang in das Wissens- und Dienstleistungszeitalter ab etwa Anfang/Mitte der 1980er Jahre änderte sich das. Die Ansprüche der Kunden an die Produkte stiegen, was sich in immer anspruchsvolleren Anforderungen an Systeme und Software äußerte. Durch die Globalisierung befand sich quasi jeder mit jedem im Wettbewerb. Die Marktdynamik stieg, und damit auch die Häufigkeit von Anforderungsänderungen und anderen Überraschungen. Hinzu kam der rasante technologische Fortschritt, vor allem beschleunigt durch den Siegeszug des Internets. Das zeigte sich in einer kontinuierlichen Steigerung sowohl der organisatorischen als auch der technischen Komplexität in der Softwareentwicklung.

Die zentrale Steuerung der Organisation durch das Management, wie es noch im Taylorismus üblich war, versagte zunehmend. Die Zahl gescheiterter Software-Entwicklungsprojekte nahm zu. Allerdings lernte man nur selten aus diesen Fehlern. Es wurde weiterhin versucht diesen neuen Herausforderungen mit den alten Denkweisen und Werkzeugen aus dem Industriezeitalter zu begegnen, z.B. mit dem im klassischen Projektmanagement häufig praktizierten Wasserfall-Ansatz. Der Taylorismus war in vielen Unternehmenskulturen noch sehr tief verankert; man konnte sich dort häufig noch nicht einmal vorstellen, völlig anders zu arbeiten und die Organisation umzustellen um sie dem dynamischen Umfeld anzupassen. Zudem befürchteten viele klassisch geprägte Manager einen Kontroll- und Machtverlust.

Das Agile Manifest ist ein Appell von Softwareentwicklern an ihr Umfeld, diesen notwendigen Kultur- und Wertewandel zuzulassen! Es transportiert letztendlich nichts anderes als ein modernes, auf Vertrauen basierendes Leadership-Mindset. Agilität ist weder ein Tool, noch ein Prozess, und schon mal gar keine Projektmanagement-Methode, sondern es ist eine Haltung und definiert einen Wertekanon. Es beschreibt, wie Software-Entwickler gerne mit ihren Kunden und anderen Stakeholdern zusammenarbeiten möchten und welche Werte ihnen dabei wichtig sind: Vertrauen, Interaktion, Kommunikation, Professionalität, voneinander Lernen und Zusammenarbeit auf Augenhöhe.

Ich stimme daher dem von Eberhard Wolff in seinem o.g. Blogartikel gezogenen Fazit zu: Wenn die Unternehmen diesen grundlegenden Wandel in der Kultur nicht mitmachen, wird das Ergebnis allenfalls ein mehr oder minder halbherziger „agiler Prozess“ sein. Ein Scrum-Theater, bei dem die Beteiligten wie Schauspieler einen Ablauf ritualisiert nach Drehbuch abarbeiten. Und ich stimme auch meiner Kollegin Kim zu, dass es als Grundlage für diesen Wandel in der Wertekultur eines Unternehmens ein positives, auf Vertrauen und Augenhöhe basierendes Menschenbild braucht. Eine Kultur, in der bei Fehlern keine Schuldigen gesucht werden, sondern diese als wichtige Lernerfahrung verstanden werden. Ist diese essenzielle Grundlage, sowie auch eine Bereitschaft für einen Kulturwandel nicht vorhanden, kann eine Transformation hin zu mehr Agilität in den Teams, und erst recht in der gesamten Organisation, nicht funktionieren.

Vielleicht wäre es ein guter erster Schritt einfach mal den Softwareentwicklern wieder mehr Spielraum und Kompetenzen zu geben, damit diese so arbeiten können, wie es für sie und insbesondere auch den Kunden wertvoll ist. Überlassen wir die Ausgestaltung von Agilität doch vor allem besser denen, die die Idee dazu hatten! Das darf natürlich andere Projektbeteiligte nicht grundsätzlich ausschließen.

Wie stehen Sie zu diesem Thema? Haben Sie auch schon Erfahrungen mit erfolgreichen oder gescheiterten Transformationen hin zu mehr Agilität gemacht? Was lief gut, was lief nicht so gut? Ich freue mich über Ihre Diskussionsbeiträge.

Braucht Agilität einen Neustart?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.