Episode 12: Wo kommt der Begiff „agil“ denn her?

Alle sollen alles „agil“ machen. Diese Forderung hört man oft. Selbst Politiker fordern dies. Die meisten Menschen, die solche Forderungen stellen, wissen vermutlich überhaupt nicht was „agil“ bedeutet. Heute gehen wir dem Modewort ein wenig auf den Grund.

Die Vorgeschichte

Der Begriff hat sich in der Software-Entwicklung entwickelt. Dort stand man schon immer vor dem Problem, dass Software-Entwicklung schnell zu großen Projekten führt.

Software Projekte sind groß und teuer. Vor allem das amerikanische Pentagon ist ein großer Auftraggeber. Dort hat man schon früh festgestellt, dass es Unternehmen gibt, die einigermaßen zuverlässig zu Resultaten kamen. Andere Unternehmen kamen öfter in Schwierigkeiten und brachten keine brauchbaren Resultate.

Das klingt so, als wären Software Entwickler alles Dilettanten. Bei der Entwicklung von Software kommen schnell mehrere Dutzend Menschen zusammen – oft verteilt auf unterschiedlichen Unternehmen. Es entstehen mehrere Hundert Dateien Programmcode, also für Menschen schwer lesbare Texte enthalten. In Summe kommen da Zehntausende oder Hunderttausende Programmzeilen zusammen. Oft werden Bibliotheken oder Produkte von anderen Herstellern eingebunden. Das Resultat ist also unüberschaubar und hochkompliziert.

Nun kommt noch die Dynamik der Erstellung dazu – täglich entstehen neue Versionen von diesen Dateien. Da kann es vorkommen, dass gestern noch alle Teile zusammen funktioniert haben. Und die Änderungen eines Tages dazu führen, dass es nicht mehr funktioniert. Dann ruft ein Kunde an und möchte eine kleine Änderung an seiner Version des Systems haben. Kein Problem? Naja, die Version, die bei diesem Kunden läuft hat die Software-Entwicklung vor 3 Monaten verlassen. Nun muss man diesen Stand wieder herstellen und dort die Änderungen vornehmen. Gleichzeitig muss man diese Änderungen in die aktuelle Version übernehmen, sonst würde die Erweiterung beim Kunden mit der nächsten Aktualisierung wegfallen.

In den 80ern hat man begonnen nach den Ursachen für Erfolg oder Scheitern zu suchen. Dabei entstand eine Sammlung von Praktiken (siehe CMMI), die den Erfolg erhöhen. Dieses Modell erhöht die Prozessreife von Software Unternehmen stufenweise. Die Praktiken sind Stufen zugeordnet und müssen nicht alle sofort umgesetzt werden, sondern man kann Stufe um Stufe neue Praktiken einführen und damit zuverlässiger werden.

Man muss sich das so vorstellen, dass diese Praktiken sehr einfach und einleuchtend klingen z.B. „Sorge dafür, dass Änderungen und Anforderungen in beiden Richtungen verknüpft sind“. Das ist vollkommen sinnvoll: man möchte ja wissen wie eine Anforderung an das System umgesetzt wurde und umgekehrt kann man bei einer Änderung dadurch herausfinden, welche Anforderung an das System diese erforderlich gemacht hat. In der Praxis stecken da viele Schwierigkeiten dahinter. Da eine Anforderung möglicherweise viele Änderungen bedingt und eine Änderung möglicherweise mehrere Anforderungen betrifft. Man muss also technische Systeme dafür auswählen, einrichten und betreiben und die Gewohnheiten der Software Entwickler ändern. So eine Veränderung kann viele Monate in Anspruch nehmen.

Das Reifegrad-Modell schenkte der Welt den Pfad zur Professionalität. Man konnte nun systematisch besser werden. Nun könnte man vermuten, dass damit alle Probleme gelöst wären. Aber die Probleme in der Software-Entwicklung blieben.

Nicht nur kompliziert, sondern komplex

Es hatte einen einfachen Grund, warum die Professionalität der Prozesse nicht ausreichte. Es lag am Wasserfallmodell. In der Software-Entwicklung gibt es logische Phasen:

  • zunächst ermittelt ein Spezialist die Anforderungen, also was der Auftraggeber braucht
  • dann entwickelt ein Software-Architekt einen groben Entwurf. Dort sollen alle Aspekte der Lösung berücksichtigt werden, allerdings nur als ein grobes Konzept.
  • Dieses Konzept kann man dann in mehreren Stufen verfeinern und ergänzen, z.B. durch ein Konzept zur Qualitätssicherung
  • Wenn die Konzepte stehen – meist mehrere 100 Seiten – beginnt die Codierung in der Programmiersprache
  • Wenn die einzelnen Bausteine kodiert wurden, dann werden sie zusammengefügt,
  • getestet und
  • für die Auslieferung gepackt.

Je nach Modell unterscheiden sich diese Phasen, aber ganz grob sind das die Schritte bei der Software-Entwicklung. Der Name Wasserfall kommt daher, dass man diese Phasen wie Wasserbecken übereinander ansehen kann. Das Wasser durchläuft diese Becken und stürzt in einem Wasserfall in das nächste Becken darunter. Manchmal muss man Wasser „zurück pumpen“. Wenn z.B. ein Fehler entdeckt wurde, dann muss man das Wasser bergauf pumpen, also den Fehler beseitigen und dann alle nachfolgenden Phasen nochmal durchlaufen. Das Bild suggeriert bereits, dass man Rücksprünge vermeiden möchte.

Bis die Software bei den Anwendern in Benutzung ging, hatten sich schlicht die ursprünglichen Anforderungen weiterentwickelt. Weil neue Gesetze heraus kamen, weil der Mitbewerber bereit mehr konnte oder es neue Betriebssysteme etc. gab. Oft wollte oder konnte man das fertige System dann nicht in Betrieb nehmen, sondern musste schnell die Änderungen nachziehen.

Kunden sind oft nicht bereit so lange zu warten. Außerdem können sie nicht zu Beginn alle Anforderungen sicher benennen. Wie auch, das neue System verändert das Umfeld und in einem veränderten Umfeld braucht man ein angepasstes System.

Der Wasserfall ist ein tolles Instrument, wenn man in einer stabilen Umgebung arbeitet. Wenn sich die Bedingungen allerdings regelmäßig ändern, dann kommt der Wasserfall einfach nicht mehr hinterher.

In den 90ern hat man sich Gedanken über einen besseren Prozess gemacht. Im Kern wurde hier von Iterationen gesprochen. Das kann man sich vereinfacht so vorstellen, dass man versucht das System nicht in einem Rutsch zu entwickeln, sondern in Scheiben. Eine Art Salamitaktik für Software-Entwicklung. Jeder dieser Scheiben ist eine Iteration, ein kleiner Wasserfall. Bekanntester Vertreter der iterativen Prozesse war der Rational Unified Prozess. Obwohl die Gedanken im RUP durchaus gut waren, er scheiterte in der Praxis weil er noch im alten Paradigma verhaftet war.

Dann kam der agile Befreiungsschlag

Es gab in den 90ern auch Menschen, die einen grundsätzlich anderen Ansatz suchten. Da entstanden so Konzepte wie „Extreme Programming“. Hier ging man noch einen Schritt weiter, man hat nicht einfach den Wasserfall schneller rotieren lassen. Man hat das ganze Vorgehen von Prozessen gelöst um so viel schneller und freier auf die Einflüsse von außen reagieren zu können. Um das zu verdeutlichen nur drei Beispiele aus Extreme Programming:

  • Der Programm-Code gehört dem gesamten Team und jeder im Team fühlt sich für den Code verantwortlich. Üblich war es bis dahin den Code auf die Mitarbeiterinnen und Mitarbeiter aufzuteilen und jede und jeder hat sich nur für seinen Teil verantwortlich gefühlt.
  • Es wurde ein täglicher, kurzer und strukturierter Austausch durchgeführt. Davor gab es typischerweise wöchentliche Treffen, die eher länger gingen und ohne Struktur waren – oft genug gab es lange Monologe durch den Projektleiter.
  • Prozesse sollten durchgeführt werden, wo und soweit sie nützlich sind. Sonst war der Prozess oft ein Selbstzweck, der unbedingt einzuhalten ist. Er war nicht immer schlecht, aber manche Teile sind einfach nicht passend. Bei einer Abweichung machte man sich angreifbar, sinnlose Prozesse durchzuführen war die „sichere“ Variante.

Im Jahr 2001 trafen sich dann die Vordenker um das „Agile Manifest“ zu verabschieden. Hier ist auch der Begriff „agil“ ausgewählt worden, davor sprach man eher von leichtgewichtig oder iterativ.

Seither ist in der Software-Entwicklung der Siegeszug von „agil“ nicht mehr aufzuhalten. Nahezu alle Software Entwicklungsprojekte werden inzwischen agil angegangen. Als Allheilmittel für alles wird es nun für alle passenden und unpassenden Problemstellungen kopiert: agiles Management, agile Bildung, agile Politik, usw.

Was ist bei agil anders?

Agil ist kein schwammiger Begriff, den jeder mit beliebigen Inhalten füllen kann. Im Agilen Manifest von 2001 sind die agilen Werte und die agilen Prinzipien enthalten.

Die agilen Werte

Bei den Werten hat man immer Begriffspaare gebildet. Zum Beispiel steht da „funktionierende Software“ einer „umfassenden Dokumentation“ gegenüber. Nun geht es nicht darum, Dokumentation abzuschaffen und sich allein auf funktionierende Software zu fokussieren. Der Dokumentation wird durchaus auch Wert unterstellt, jedoch bringt eine tolle Dokumentation nichts, wenn die Software nicht läuft. Daher sollte das Augenmerk zuerst auf die funktionierende Software gerichtet werden, die Dokumentation lässt sich auch nach dem Abgabetermin noch nachziehen.

Die anderen drei Begriffspaare sind:

  • Individuen und deren Interaktion soll Vorrang vor Prozessen und Werkzeugen haben.
  • Wichtiger als wasserdichte Vertragsverhandlung ist die Zusammenarbeit mit den Kunden.
  • Es ist wichtiger auf Veränderung zu reagieren als einen Plan zu befolgen.

Diese Werte kann man im agilen Manifest nachlesen, inklusive der Liste der Unterzeichner.

Wow, das ist also der ganze Zauber?

Das klingt doch ganz simpel und fast selbstverständlich. So wie heute die doppelte Buchführung der Standard im kaufmännischen Bereich ist, so sind es diese 4 Gewichtungen in der Software-Entwicklung.

Mit diesen 4 einfachen Gewichtungen verschiebt sich der Fokus. In den agilen Prozessen wird daher nicht beschrieben, wie das Software Engineering funktioniert, dort tauchen die oben beschriebenen Phasen typischerweise nicht mehr auf. Stattdessen werden soziale Prozesse beschrieben: wie oft wer mit wem interagieren soll.

Wobei man natürlich auch erkennen muss, dass es gerade im agilen Umfeld eine Reihe von sehr stringenten Prozessen gibt. Wobei man alles daran setzt diese Prozesse von Maschinen automatisiert erledigen zu lassen. So wird die Software nicht mehr in einer Phase, sondern jede Nacht oder noch häufiger Zusammengebaut – das Resultat durchläuft automatisierte Tests. Ganz nach dem Motto: wenn es anstrengend ist, dann mach es öfter. Man will vermeiden, dass es Schritte gibt, die schwergängig sind und den Prozessdurchlauf bremsen.

Anstatt Kunden mit einer revisionssicheren Dokumentation zu erschlagen und ihn für alle Abweichungen, die er davon haben möchte, bluten zu lassen. Geht man in den Dialog mit den Kunden. Man zwingt den Kunden damit nicht mehr die mehrjährigen Entwicklungszeiten als Bürde auf, sondern versucht in keinen Schritten die Kundenlösung entstehen zu lassen.

Während man sich bei der klassischen Entwicklung mit umfangreichen Verfahren um Änderungen kümmern musste, so kann man diese im agilen Umfeld nahezu ignorieren. Es dauert ja nie lange, bis der nächste Zyklus beginnt, dann kann man die Änderungen dort einfach einbringen. Entwicklung und Veränderung konkurrieren nun nicht mehr sondern verschmelzen.

Alles muss agil sein – oder nicht?

In diesem Artikel habe ich sehr weit ausgeholt. Das scheint mir allerdings auch sinnvoll um abschätzen zu können, welche Probleme man in der Software-Entwicklung hatte, die man durch Agilität gelöst hat.

Agilität ist allerdings nicht die Lösung für alle Problemstellungen. Dort wo man effiziente Prozesse einsetzten kann, sind diese immer auch agilen Methoden überlegen. Bei einer komplexen Problemstellung, kommt der Prozess jedoch öfter aus dem Takt. Mit Überraschungen kommen effiziente Prozesse einfach nicht gut zurecht. Dort schlägt die Stunde der agilen Methoden.

Wenn es darum geht z.B. einen vorgegebenen Hamburger in großer Stückzahl und preisgünstig zuzubereiten, dann entwickelt man dafür optimierte Abläufe. Diese Abläufe werden dann konsequent umgesetzt und systematisch weiter optimiert.

In der Gourmet-Küche wird man ebenfalls viele effiziente Prozesse finden. Allerdings nicht für fertige Gerichte. Hier sind die Prozesse das Handwerkszeug für die Köche: schälen, schneiden, garen, blanchieren, flambieren, usw. In diesen Handgriffen steckt können, aber keine Kunst. Diese ergibt sich aus der passenden Kombination dieser Handgriffe. Gerichte werden nach Saison, Tageslaune, Mode, Witterung, Gästen, etc. zubereitet. Wenn ein Gericht nicht mehr so gut ankommt, dann wird es weiterentwickelt oder ersetzt – nichts soll gewohnt oder langweilig schmecken. Die Gerichte sollten neue Geschmackserlebnisse und -überraschungen ermöglichen.

Mach es agil, aber nicht um jeden Preis

Meine Bitte an dich lautet: laufe nicht blind dem agilen Trend hinterher. Schaue dir die Problemstellungen genau an. Beim täglichen Verbuchen von Rechnungen nützen agile Methoden nichts – dadurch geht es nicht schneller oder besser. Bei einer umfassenden Rechnungsprüfung, kann man mit agilen Methoden zwar insgesamt nicht mehr prüfen, aber möglicherweise mehr Unstimmigkeiten entdecken. Wie man das macht? Dazu schreibe ich am besten einen neuen Artikel.

Frag auch den einen oder anderen selbsternannten Agilitätsexperten, wie die agilen Werte in deinem Fall einen Nutzen stiften. Wenn dann nur ein Gefasel von schneller, mehr, besser, effizienter, flexibler, bla-bla-bla kommt, dann weißt du Bescheid 🙂

Falls dir diese Episode gefallen hat, dann abonniere den Podcast auf iTunes, Instacast, Downcast, PodGrasp oder deinem Lieblings-Podcast-Player. Das geht einfach, du bekommst neue Episoden dann automatisch und verhilfst dem Podcast zu mehr Aufmerksamkeit.

Veröffentlicht am 23.3.2018

  • […] Episode 15: Mit 12 einfachen Prinzipien zur Agilität – Teil 3 – schwarm-coach.de bei Episode 12: Wo kommt der Begiff „agil“ denn her? […]

  • >