Die agilen Werte und Grundsätze (siehe http://www.agilemanifesto.org) wurden im Februar 2001 in Snowbird, Utah, USA durch 17 Experten[1] aus erfahrenen Softwareentwicklern und Methodikern in einem Gremium beschlossen.
Der agile Ansatz entstammt primär aus der Softwareentwicklung, die von sehr viel Dynamik gezeichnet ist und in den seltensten Fällen stabile Rahmenbedingungen (siehe »Rahmenbedingungen eines Projektes in der Softwareentwicklung«) gegeben sind[2].
Später wurden die agilen Werte und Grundsätze auch auf andere Disziplinen in einer Organisation, wie beispielsweise dem Produktmanagement[3] oder dem Personalmanagement[4] aber auch in Werte und Leitsätze von innovativen und agilen Organisationen übertragen.
Der Begriff »agil« soll zum Ausdruck bringen, dass das Management und die Steuerung von Projekten und Prozessen dynamisch und flexibel auszurichten ist und auch die Möglichkeit gegeben sein muss, bei turbulenten und sich schnell ändernden Marktgegebenheiten Anforderungen und die Reaktion auf Veränderungen effektiv umsetzen zu können[5].
»Agil« bedeutet aber auf keinen Fall »leichtgewichtig«, sondern hebt die positiven Aspekte geringer Führungsintensität heraus[6].
Diese vier Wertepaare fasste man anschließend in dem »agilen Manifest« zusammen:
| 1. Individuen und Interaktionen | mehr als Prozesse und Werkzeuge[7] |
| 2. Funktionierende Software | mehr als umfassende Dokumentation[8] |
| 3. Zusammenarbeit mit dem Kunden | mehr als Vertragsverhandlungen[9] |
| 4. Reagieren auf Veränderung | mehr als das Befolgen eines Plans[10] |
Das agile Manifest bildet das Fundament der agilen Prinzipien, Methoden und Vorgehensweisen (siehe Abbildung unten »Agile Werte und Grundsätze (Übersicht)«) im agilen Projektmanagement. Es stellt u.a. in Punkt 1. primär den Faktor Mensch in den Mittelpunkt des Vorhabens, was in der Entwicklung von Software ein wesentlicher kritischer Erfolgsfaktor ist, da Software i.d.R. durch die Zusammenarbeit (collaboration) und durch die Wechselwirkung (interaction) von Menschen (individuals) entsteht.
Das agile Manifest postuliert u.a. die Verbesserung der Kundenzufriedenheit[12] und die Verbesserung der Wertschöpfung in Softwareprojekten. Im Vordergrund aber stehen die wirtschaftlichen Ziele des Projektes und das Erreichen der Projektziele[13], ohne die Kundenzufriedenheit zu gefährden. Das Manifest erlaubt es Veränderungen in kleinen Schritten auszurollen, Rückmeldung wieder einfließen zu lassen und verhindert regelrecht große Veränderungen in einem Schritt umzusetzen.
Bei der Anwendung der Werte und Grundsätze ist es wichtig, sich darüber im Klaren zu sein, dass die Wertepaare bzw. Grundsätze relativ zueinander gemeint sind. Natürlich sind in der Softwareentwicklung auch Prozesse und Werkzeuge Erfolgsfaktoren, aber im Zweifelsfall gibt man den Individuen oder dem Team und deren Interaktionen i.d.R. die höhere Priorität.
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
In den meisten Projekten, speziell in größeren Unternehmen gibt es aus der Organisation heraus bereits vordefinierte Prozesse, die eine Projektumsetzung ausführen muss, wie beispielsweise vordefinierte Prozesse für die Anforderungserhebung oder das Reporting zum Management. Sind solche Prozesse noch nicht vorhanden, entsteht mit der fortschreitenden Zeit meist der Wunsch aus dem Management heraus, gewisse Prozesse zu standardisieren und unternehmensweit Werkzeuge einheitlich zu nutzen.
Aus Sicht des Managements ist dieser Wunsch auch plausibel und in den meisten Fällen auch gerechtfertigt, da standardisierte Prozesse und einheitliche Tools unterstützend die Qualität erhöhen und Fehler vermeiden.
Die Kehrseite der Medaille ist aber auch, dass durch festgelegte Prozesse und Aktivitäten von Mitarbeitern strikt gefordert werden, obwohl diese Mitarbeiter vielleicht ein effizienteres Vorgehen aus ihrer Alltagspraxis kennen oder aus ihrer Erfahrung bessere Methoden einsetzen könnten. Trotz allem werden diese Aktivitäten dann nach dem vorgegebenen Prozess-Schema ausgeführt. In der Softwareentwicklung lassen solche Prozesse, sofern diese schwergewichtig sind, das Projekt in den meisten Fällen scheitern. Man kann sich hinter solchen steifen Prozessen regelrecht verstecken und sogar als valide Argumente für ein Scheitern darstellen. So ist es nicht selten, dass jemand als völlig valides Argument vorbringt, dass es der Prozess so vorgesehen hat, man es hätte anders machen können, aber nicht konnte. Das mag für den Mitarbeiter eine Art Absicherung sein, aber dem Unternehmen oder dem Projekt bringt das relativ wenig. Agilität muss deshalb vom Mangement bis zu den Projektmitarbeitern gestalten und gelebt werden um effektiv und letztendlich effizient zu sein.
Der erste Punkt des agilen Manifests weist explizit darauf hin, dass man ebenso von einem klassischen Projektmanagement ausgehend, neben den standardisierten und formalen Aktivitäten, ausreichend Freiraum für individuelle Handlungen und Handlungsalternativen schaffen und die Interaktionen zum Beispiel durch genügend Kommunikation und direktem Informationsaustausch fördern sollte.
Die Kommunikation und der Informationsaustausch stellt die Bedeutung von Kooperation und Zusammenarbeit der einzelnen Teammitglieder heraus und klassifiziert den Mensch als Individuum und das Team als kritischen Erfolgsfaktor.
Funktionierende Software mehr als umfassende Dokumentation
Dieser Grundsatz des agilen Manifests bedeutet nicht, dass eine gut verfasste Dokumentation geringer geschätzt wird als eine funktionierende Software, sondern weist auf die Angemessenheit von Dokumentation hin. Des Weiteren priorisiert dieser Grundsatz die Kommunikation und den Wissenstransfer von Mensch zu Mensch höher. In der Projektpraxis hört man auch oft den Ausspruch »Solange die Dokumentation nicht fertig ist, beginne ich nicht mit der Implementierung«.
Der o.g. Grundsatz soll in diesem Zusammenhang vermeiden, dass man die einzelnen Phasen strikt voneinander trennt, da das in der Projektpraxis in den seltensten Fällen möglich ist. Der Entwurf, die angemessene Dokumentation und das Testen sollen hier eine in sich verwobene Einheit bilden. Ein weiterer Punkt des Grundsatzes ist, dass das einzige Fortschrittsmaß lauffähige Software ist und nicht die Dokumentation.
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
Dieser Grundsatz soll vermeiden, dass man an veralteten Leistungsbeschreibungen und Anforderungen festhält. Vielmehr soll der Kunden in den Mittelpunkt gestellt werden und in enger Abstimmung mit ihm eine konstruktive und vertrauensvolle Zusammenarbeit fördern.
Die Kundenzufriedenheit ist der oberste Maßstab für den Erfolg, die aber von beiden Seiten, also Auftraggeber und Auftragnehmer unterstützt werden muss. Erst wenn ein Kunde ein System oder eine Anwendung bedient oder gesehen hat, ist er in der Lage explizit zu formulieren, wie seine Anwendung bzw. sein System aussehen soll und was noch geändert werden muss. Der Grundsatz fördert zum Beispiel die Aufnahme von Erwartungshaltungen an ein System oder an eine Anforderung.
Dies kann grundsätzlich nur erfolgen, wenn der Kunde bzw. das Projektumfeld das auch zulässt und Verträge im Sinne der Agilität ggf. geändert werden können. Verträge sollten demnach ebenfalls agil oder zumindest veränderbar oder offen gestaltet sein. Ein Vertrag ist somit auch eine Art Dokumentation auf oberster Ebene (siehe Überschrift »Funktionierende Software mehr als umfassende Dokumentation«) im Rahmenverhältnis zwischen Auftraggeber und Auftragnehmer. Man sieht hier, dass der Wunsch vom Kunden, agil vorzugehen, mit dem Sicherheitsdenken, alles vertraglich zu verschriftlichen und in Zement zu meiseln, im Widerspruch steht und Agilität meist nur als Worthülle im Gesamten fungiert. Meist sieht man nur die umsetzenden Teams nach agilen Methoden arbeiten, was aber dem Sinn des agilen Vorgehens widerspricht.
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Während des Projektverlaufs können sich Anforderungen, Randbedingungen und das Verständnis von projektspezifischen Problemfeldern, sowohl auf Kunden- als auch auf der Lieferantenseite ändern. Dieser Grundsatz soll vermeiden, dass beide Seiten eher einem Plan als auf Veränderungen reagieren. Das Team muss auf beiden Seiten schnell auf Veränderungen reagieren können und das auch wollen.
Auch hier ist es leider allzuoft Praxis, dass zwar von Kundenseite das Vorgehensmodell agil ausgewählt und gewünscht wird, aber letztendlich über eine längere Laufzeit Verträge, die mit dem Kunden geschlossen sind einen widersprüchlichen Einfluss auf die Agilität haben.
Der letzte Punkt des agilen Manifests eignet sich sehr gut noch einmal den Einsatz der Agilität zu etabilieren. Agilität funktioniert am Besten wenn vom Management (und Vertag) bis hin zum Team alles agil ist und die Werte und Prinzipien auch gelebt werden können.
[1] Die 17 Experten sind auf der Website agilemanifesto.org aufgeführt.
[2] Gernert, Christiane: Agiles Projektmanagement: Risikogesteuerte Softwareentwicklung, 1. Auflage; Carl Hanser Verlag, München/Wien; 2003; S. 2.
[3] Pichler; Roman: Agiles Produktmanagement mit Scrum: So entwickeln Sie Produkte, die begeistern; 1. Auflage; Addison-Wesley Longman Verlag; München; 2012;
[4] Gloger, Boris, Häusling, André: Erfolgreich mit Scrum – Einflussfaktor Personalmanagement, Finden und Binden von Mitarbeitern in agilen Unternehmen; 1. Auflage; Carl Hanser Verlag; München; 2011.
[5] Highsmith, James A.: Agile project management; creating innovative products; 1.Auflage; Addison-Wesley Longman; Amsterdam; 2004; S. 16.
[6] projektmagazin.de; Agiles Projektmanagement; http://www.projektmagazin.de/glossarterm/agiles-projektmanagement; 18.12.2009.
[7] Originaltext: Individuals and interactions over processes and tools
[8] Orginaltext: Working software over comprehensive documentation
[9] Orginaltext: Customer collaboration over contract negotiation
[10] Orginaltext: Responding to change over following a plan
[11] agilemanifesto.org; Manifesto for Agile Software Development; http://agilemanifesto.org/iso/de/; 12.01.2012.
[12] Kunden können in diesem Zusammenhang auch Fachabteilungen eines Unternehmens sein.
[13] Katzenbach, Jon R., Smith, Douglas K.: Teams, Der Schlüssel zur Hochleistungsorganisation; 1. Auflage; Wirtschaftsverlag Carl Ueberreuter; Wien; 1993; S. 229 ff.
No Comments