Was ist Agile?

Was ist Agilität, wozu ist sie gut und wie vermeidet man, dass „Agile“ zum Buzzword wird.

Grundsätzlich handelt es sich bei Agilität um eine Sammlung von Werten und Prinzipien rund um die Organisation von und Arbeit in Projekten und darüber hinaus.

Klassisches Projektmanagement…

Um Agilität besser verstehen zu können, ist es zunächst sinnvoll zu betrachten, was sich hinter dem Begriff „Projekt“ verbirgt.

Hinweis: Wenn Sie bereits wissen, was ein Projekt ist bzw. was Projekte mit Wasserfällen zu tun haben, können Sie die folgenden beiden Absätze überspringen.

Zunächst gibt es Leute, die gemeinsam mit dem Kunden ein möglichst genaues Konzept davon erstellen, was am Ende herauskommen soll. Auf Basis dessen erarbeiten andere Experten einen ebenfalls möglichst detaillierten Plan. Dieser dient meist auch als Grundlage für Verträge zwischen Dienstleister und Kunden und soll darüber hinaus auch die Vorlage für die Personen bieten, die nun die eigentlichen Arbeiten zur Umsetzung beginnen. Sobald alle Aspekte des Vorhabens fertig gestellt sind, werden idealerweise verschiedene Test- und Abnahme-Prozesse durchlaufen, bevor der Kunde schlussendlich das Ergebnis ausgehändigt bekommt und den vereinbarten Festpreis zahlt.

Dahinter steckt das Bild des mehrstufigen Wasserfalls. Genauso wie Wasser nur in eine Richtung fließt, gibt es in einem „perfekten“ Projekt beim Erreichen einer neuen Phase kein Zurück mehr in die vorhergehende.

… und seine Grenzen

Während es durchaus Umfelder gibt, in denen dieses klassische Projekt-Vorgehen seit jeher funktioniert (z.B. beim Hausbau), so stößt man bei bestimmten anderen Themen aber auch häufiger auf Probleme.

Darüber, wie man sein eigenes Umfeld erkennt und welches Vorgehen wann und vor allem wieso passt wird es noch einen eigenen Artikel geben.

An dieser Stelle soll die Behauptung eines erfahrenen ITlers genügen, dass die Entwicklung von Software eine gewisse Tendenz hat, Probleme zu verursachen, die wiederum dazu führen, dass sich Termine verschieben und/oder Kosten steigen.

Wenn ITler Ski fahren

17 erfahrene ITler waren es auch, die sich 2001 auf einer Skihütte in Utah trafen, um neben anderen Dingen, die man an einer solchen Lokalität üblicherweise unternimmt, auch in einen Erfahrungsaustausch zu treten und darin nach Gemeinsamkeiten zu suchen. Als Ergebnis verfassten sie zusammen das „Manifest für agile Softwareentwicklung“ und 12 dazugehörige Prinzipien. Diese bilden einen so zentralen Kern der Agilität, dass es dafür einen eigenen Artikel geben wird.

Und was ist nun Agilität?

Agilität ist also keine Methode bzw. eine Sammlung an Regeln oder gar Meetings und Rollen sondern zu allererst eine Denkweise, ja Philosophie für eine geänderte (Zusammen-)Arbeit.

Auf die eigentliche Arbeit in Projekten bezogen bedeutet dies ein kleinteiligeres Herangehen. Anstatt einer Laufzeit von mehreren Monaten bis Jahren (bei Projekten mit staatlicher Beteiligung ggf. auch Jahrzehnten) wird versucht, in deutlich kürzeren Planungs-, Umsetzungs- und Auslieferungszyklen von wenigen Wochen bereits einen frühen und ab da kontinuierlich weiterentwickelten Mehrwert für den Kunden zu liefern.

Zudem bietet ein solches Vorgehen die Möglichkeit, die so gewonnenen Einsichten direkt in die weitere Entwicklung und Priorisierung einfließen zu lassen. Das betrifft neben den eigentlichen Arbeitsinhalten und -ergebnissen vor allem auch die Art der (Zusammen-)Arbeit im Team.

Neben diesem Fokus auf die permanente Generierung von Mehrwert für den Kunden und der ständigen Verbesserung der zugrunde liegenden Prozesse seitens der umsetzenden Dienstleister birgt der agile Ansatz aber auch die Möglichkeit einer deutlich detaillierteren und fundierteren Priorisierung des Projekts für sich, aber auch projektübergreifend.

Während es im klassischen Projektmanagement-Umfeld meist nur eine grobe Möglichkeit zur Priorisierung von Projekten untereinander gibt (Projekt A ist wichtiger als Projekt B und muss daher erst vollständig abgeschlossen werden) eröffnet dieser kleinteiligere Ansatz die Möglichkeit, die einzelnen Projekte aufzuteilen und diese Teile untereinander zu priorisieren. Durch die kürzeren Abstände zwischen den Auslieferungen von funktionstüchtigen Arbeitsergebnissen ergeben sich zudem deutlich kürzere Feedback-Zyklen. Diese erlauben es, anhand konkreter Daten aus der Praxis, Entscheidungen darüber zu treffen, ob Teil 1 von Projekt B ggf. erfolgversprechender ist als der nächste Teil von Projekt A und somit vorgezogen werden sollte.

Also nur noch „agile“?

Auch wenn die genannten Punkte nur eine Auswahl möglicher Vorteile agiler Vorgehensweisen darstellen möchte ich nochmal auf das verweisen, was ich bereits weiter oben erwähnt habe: Jedes Umfeld braucht die dazu passenden Werkzeuge. So gut ein agiler Ansatz in einem Software-Entwicklungs-Projekt für ein bestimmtes Team passen kann (aber nicht muss!), so wenig wird man ihn beispielsweise beim Hausbau gebrauchen können. Es ist also immens wichtig, sich über sein konkretes Umfeld bewusst zu werden und erst basierend darauf auf die Suche nach den für einen selbst passenden Werkzeugen zu gehen. Genau dafür kann der Einsatz eines Agile Coach nützlich und hilfreich sein.

Denn Flugzeuge aus Stroh fliegen nicht

„Das Kriegsmaterial, das während des Zweiten Weltkrieges massenhaft von der US-Armee auf diese [polynesischen, Erg. d. Autors] Inseln abgeworfen wurde […] brachte drastische Änderungen des Lebensstils der Inselbewohner mit sich: Sowohl die Soldaten als auch die Einheimischen, die sie beherbergten, wurden mit Materialmengen regelrecht überschüttet.
[…]
Mit dem Kriegsende wurden die Flughäfen verlassen und kein neues „Cargo“ wurde mehr abgeworfen. Darum bemüht, weiter Cargo […] zu erhalten, imitierten Kultanhänger die Praxis, die sie bei den Soldaten, Seeleuten und Fliegern gesehen hatten. Sie schnitzten Kopfhörer aus Holz und trugen sie, als würden sie im Flughafentower sitzen. Sie positionierten sich auf den Landebahnen und imitierten die wellenartigen Landungssignale. Sie entzündeten Signalfeuer und  -fackeln an den Landebahnen und Leuchttürmen […] [und, Erg. d. Autors] bauten […] zum Beispiel Flugzeugmodelle in Originalgröße aus Stroh oder schufen Anlagen, die den militärischen Landebahnen nachempfunden waren, in der Hoffnung, neue Flugzeuge anzuziehen.“

(Auszug aus dem Wikipedia-Artikel zum Thema Cargo-Kult)

Vergleichbare Praktiken sind leider auch immer wieder bei Firmen zu beobachten, die beim krampfhaften Versuch agile Methoden einzuführen an einem solchen falschen Verständnis scheitern. Dies führt bei den allermeisten Beteiligten eines solchen Prozesses nicht selten zu einer nachhaltigen Abwehrhaltung gegenüber dem „verbrannten Thema“ bzw. „Buzzword“ „agile“.

Am Anfang sollte also immer die Frage stehen: Welches Problem möchte ich durch die Einführung von Agilität eigentlich lösen?