Das Manifest der Agilen Softwareentwicklung

2001 trafen sich 17 erfahrene ITler auf einer Skihütte in Utah um ihre Erfahrungen auszutauschen und darin nach Gemeinsamkeiten zu suchen. Als Ergebnis verfassten sie das „Manifest für agile Softwareentwicklung“ und 12 dazugehörigen Prinzipien.

Das Manifest der Agilen Softwareentwicklung

Im Kern besagt das Manifest, dass die 17 Personen durch ihre Arbeit in der Softwareentwicklung gelernt haben, folgende Werte zu schätzen:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software (bzw. Arbeitsergebnisse) mehr als Vollständige Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
Reagieren auf Veränderung mehr als das Befolgen eines Plans

Auch, wenn die Punkte rechts wertvoll sein können so wird den Punkten links doch ein höherer Wert zugerechnet.

Individuen und Interaktionen > Prozesse und Werkzeuge

Kennen Sie das? Es ist wieder ein Monat (/ Quartal / o.ä.) vergangen und Sie als Projektleiter müssen wieder einen dieser Status-, Projekt-, Monats- oder Quartals-Berichte anfertigen. Ob die überhaupt jemals jemand lesen wird können Sie nicht einschätzen und insgeheim haben Sie sich auch schon bei dem Gedanken ertappt, einfach mal bewusst erfundene bzw. übertrieben schlechte Daten zu verwenden um zu sehen, ob überhaupt jemand darauf reagiert. Oder kennen Sie noch das Anforderungsformular für Ihre neue Tastatur, das ausgefüllt, ausgedruckt, von Ihrem Chef unterschrieben und nach dem Einscannen -immerhin bereits elektronisch – an die IT geschickt werden muss (was deutlich einfacher wäre, hätte man nur eine funktionierende Tastatur)?

Zugegeben, diese Beispiele suggerieren vielleicht ein relativ einseitiges Bild. Natürlich gibt es durchaus Prozesse und auch Werkzeuge, die die tägliche Arbeit und vor allem auch Zusammenarbeit nicht nur unterstützen sondern nicht zuletzt auch sicherer machen können. Der erste Grundsatz des Manifests will diese auch gar nicht grundsätzlich ausschließen, sondern stellt für einzelne Situationen eine gewisse Entscheidungshilfe dar. Macht es Sinn, sich an einer eMail-Schlacht mit immer größer werdendem Verteiler zu beteiligen oder diese gar zu starten oder könnte mein Problem vielleicht auch schon durch einen Anruf bei der betreffenden Person gelöst werden? Muss es unbedingt der Anruf sein oder gibt es auch die Möglichkeit, einfach mal bei dieser Person vorbeizuschauen und das Thema persönlich zu erörtern?

Es mag banal klingen, aber im Zweifelsfall führt ein persönliches Gespräch tatsächlich am schnellsten zum Ziel. Probieren Sie’s aus!

Funktionierende Software (bzw. Arbeitsergebnisse) > Vollständige Dokumentation

Natürlich klingt dieser Grundsatz im ersten Moment wie eine Entschuldigung, seine eigene Arbeit nicht mehr dokumentieren zu müssen. Das ist damit aber nicht gemeint. Eine Dokumentation des Arbeitsfortschrittes, der Entscheidungsfindungen oder auch einfach das Benutzerhandbuch für die neue Software behalten ihre Notwendig- und damit auch ihre Wichtigkeit.

Dennoch greift auch hier wieder das obige Beispiel mit dem Status-Bericht. Was nützt der ausgefeilteste Bericht, wenn das Arbeitsergebnis nicht den Ansprüchen des Kunden entspricht? Umso schlimmer kann es sein, wenn ich mir dessen noch gar nicht bewusst bin, weil der Kunde eben nur die Berichte aber nicht den tatsächlichen Arbeitsstand kennt.

Am Ende zählt die Qualität der abgelieferten Arbeit mehr als die beste Dokumentation der selben oder des Weges dorthin. Eines der angenehmen Dinge bei der agilen Denkweise ist: Wenn Sie insgeheim der Meinung sind, ihre Zeit eigentlich sinnvoller nutzen zu können als wieder mal einen dieser Berichte zu verfassen, dann ist das vermutlich auch so und Sie dürfen und sollen versuchen daran etwas zu ändern. Wenn sich etwas falsch oder wie Zeitverschwendung anfühlt ist es definitiv einen genaueren Blick wert.

Zusammenarbeit mit dem Kunden > Vertragsverhandlungen

In einem klassischen Festpreis-Projekt dreht sich in den ersten Projekt-Phasen alles darum anhand der Kundenwünsche immer detailliertere Spezifikationen, Aufwandsschätzungen und schlussendlich Planungen für die Umsetzung zu erstellen. Basierend darauf wird früher oder später ein Vertrag zwischen Kunden und Lösungsanbieter erarbeitet in dem üblicherweise Umfang, Kosten sowie der Endtermin festgeschrieben werden.

Je nachdem wie reibungslos die Umsetzung des Projekts verläuft kommt es ggf. immer wieder zu Situationen, in denen – mit unterschiedlicher Intensität – von beiden Seiten auf eben dieses Vertragswerk (z.B. das Pflichtenheft) Bezug genommen und über unterschiedliche Auslegungen debattiert wird. Nicht selten kommt es im Rahmen solcher Diskussionen zur Eskalation des Themas über mehrere Führungsebenen bei beiden Vertragsparteien oder im schlimmsten Fall gar zur Einbindung von Juristen.

Neben der Zeit und auch der dadurch enstehenden Kosten eines solchen Prozesses leidet noch etwas weitaus wichtigeres: Das Vertrauensverhältnis zwischen dem Kunden und dem Lösungsanbieter. Das dritte Wortpaar des Manifests bezieht sich genau auf diesen Punkt: Im Zweifelsfall ist es für alle Beteiligten langfristig gewinnbringender gemeinsam zu einer gütlichen Lösung zu kommen, anstatt sich über unterschiedliche Auslegungen des Vertragswerks zu streiten. Dies stellt aber keinesfalls eine Einbahnstraße zu ungunsten des Anbieters dar, sondern meint eben insbesondere auch die Einstellung und Kompromissbereitschaft seitens des Kunden von Beginn an.

In der Praxis gibt es hierfür verschiedene Ansätze zur Vertragsgestaltung rund um agile Umsetzungen. Als Beispiele seien hier der „Agile Festpreis“ oder das Konzept „Money for nothing, Change for free“ angeführt.

Reagieren auf Veränderung > Befolgen eines Plans

Laut einer Studie der TU München scheitern (etwas) mehr als die Hälfte aller IT-Vorhaben. Das heißt die Projektdauer wird überschritten, das Ergebnis entspricht nicht den Erwartungen und/oder die Kosten stiegen gegenüber dem Plan deutlich an. Die Gründe dafür sind in der Praxis ebenso vielfältig wie unterschiedlich, führen aber am Ende immer wieder zur gleichen Schlussfolgerung, nämlich dass es Bereiche und Umfelder gibt, in denen jeder noch so detaillierte Plan an seine Grenzen stößt.

Genau dies adressiert der vierte Satz des Manifests. Anstatt zu versuchen mit immer besseren Plänen bzw. restriktiverer Arbeitsweise oder Mehrarbeit auf diese Situationen zu reagieren, ermuntert er dazu, sich auf die sich zwangsläufig ergebenden Änderungen einzulassen und aus diesen sogar einen Vorteil für den Kunden zu ziehen.

 

Ihnen sind diese vier Leitsätze immer noch zu abstrakt? Erfahren Sie auf Seite 2 mehr über die weiterführenden zwölf Prinzipien und deren deutlich konkreteren Handlungsempfehlungen.