Agile Scrum Handbuch. Frank Turley
für Systeme mit adaptiven Lebenszyklen. Diese Definition des Begriffs Agile ist viel besser als zu sagen „Agile ist eine Einstellung“.
Sprechen die Anhänger von agilen Methoden über prognostizierte Lebenszyklen (englisch: Predictive Lifecycles), verwenden sie die Bezeichnung Wasserfall. Dies gilt vor allem für IT-Projekte; kein Mensch würde sagen: „Dieses Gebäude wurde mit Hilfe der Wasserfallmethode gebaut.“
Um ganz sicherzustellen, dass Sie die Terminologie beherrschen, sollten Sie sich bewusst sein, dass das Wort Wasserfall inzwischen praktisch ein Unwort ist und dass Sie durchaus wütend und beleidigt reagieren dürfen, wenn jemand sagt, dass Sie die Wasserfallmethode verwenden! Ich schlage deshalb vor, dass wir uns in diesem Buch an die offizielle Bezeichnung halten und von prognostizierten Lebenszyklen sprechen.
■ 1.4 IST AGILE ETWAS NEUES?
Agile wird in der Regel als neue Methode beworben. Das Wort Agile für adaptive Lebenszyklen zu verwenden ist sicherlich neu, aber wie sieht es mit dem Lebenszyklus selbst aus?
Ich weiß nicht, wie es Ihnen geht, aber ich kann mir nur schwer vorstellen, dass die vielen Projekte und Programme in der langen Geschichte der Menschheit ganz ohne adaptive Lebenszyklen ausgekommen sind. Fällt Ihnen vielleicht ein Beispiel ein?
Ich kann Ihnen ein Beispiel nennen. Denken Sie einmal an eine in der Vergangenheit äußerst gängige Praxis (bzw. ein äußerst gängiges Projekt oder Programm): Krieg führen. Kann man einen Krieg mit einem prognostizierten Ansatz führen? Lässt sich alles von Anfang an planen und festlegen? Ganz bestimmt nicht. Zwar gibt es wahrscheinlich einen übergeordneten Plan, eher eine Art Strategie, aber den Krieg an sich müssen Sie Schlacht um Schlacht (d. h. in Iterationen) führen (manchmal werden möglicherweise mehrere Schlachten gleichzeitig gekämpft). Und je nach Ausgang der einzelnen Schlachten wird dann die Strategie für die weitere Kriegsführung flexibel angepasst.
Dieses Beispiel ist zwar kein angenehmes Thema, zeigt aber ganz klar, dass adaptive Ansätze nicht neu sein können.
Was also ist neu?
Irgendwann in der Vergangenheit wurden der so genannte wissenschaftliche Managementansatz und der Taylorismus zur Norm und jeder andere Ansatz galt als minderwertig oder sogar falsch. Da Taylorismus voll und ganz auf prognostizierten Systemen beruhte, dominierten diese Systeme sozusagen die ganze Welt.
Dann kam eine Zeit, in der immer mehr Projekte in der IT-Entwicklung initiiert wurden. Die prognostizierten Systeme waren für das Management dieser Projekte nicht wirklich die beste Lösung. Man versuchte zwar dies zu tolerieren, aber der Druck stieg und es kam zu Demonstrationen und schließlich zur Revolution! Und, wie das bei Revolutionen so üblich ist, frisst auch diese Revolution ihre Kinder, aber dazu ein andermal.
■ 1.5 DAS AGILE MANIFEST
Bald schon kamen die ersten adaptiven Systeme in der IT-Entwicklung zum Einsatz und wurden allmählich strukturiert und in reproduzierbare Managementsysteme überführt. 2001 schlossen sich dann einige Pioniere auf diesem Gebiet zusammen und erarbeiteten ein Manifest.
Beginnen wir mit dem Namen. Es wird erzählt, dass nach langen Beratungen zwei Möglichkeiten übrigblieben: Das Agile Manifest oder Das Adaptive Manifest. Leider fiel die Entscheidung auf Das Agile Manifest. Das Adaptive Manifest wäre die bessere Wahl gewesen, weil dies die Art der Herangehensweise beschreibt und viele Missverständnisse verhindert hätte.
Das Agile Manifest findet sich auf der äußerst fortschrittlichen und modernen Website AgileManifest.org und lautet wie folgt:
Leider wurde das Manifest selbst, nachdem es verfasst wurde, nicht mehr überarbeitet oder angepasst.
Der letzte Satz des Manifests bleibt häufig unbeachtet. Bitte lesen Sie das Manifest noch einmal durch und denken Sie dabei an den letzten Satz.
Überprüfen wir also die vier Wertaussagen:
Wertaussage 1: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
Ignoriert man die Bedeutung von Individuen und ihren Interaktionen, scheitert man in der Regel sehr schnell, denn schließlich werden Projekte von Menschen durchgeführt. Einige Manager glauben, sie könnten Probleme in diesen Bereichen mittels raffinierterer Systeme lösen, aber das funktioniert nur in den seltensten Fällen.
Schon viele von uns dachten naiv optimistisch, wir könnten mit tollen Werkzeugen Probleme lösen, die durch das Ignorieren menschlicher Aspekte entstanden sind, und mussten dann enttäuscht feststellen, dass dies nicht funktioniert. Manager geben nach wie vor enorme Summen für die Implementierung und Wartung solcher Werkzeuge aus und hoffen auf deren magische Wirkung. Tatsache ist jedoch, dass Werkzeuge Systeme nur unterstützen, aber nicht ersetzen können. Positiv ist zu vermerken, dass es sich bei diesen Werkzeugen um ausgeklügelte Softwareprodukte handelt, die in jahrelanger Arbeit entwickelt und instandgehalten werden und so viele Projekte und Jobs schaffen, die uns Investitionen ermöglichen, um über die Optimierung von IT-Entwicklungsprojekten nachzudenken.
Die Erwähnung der Prozesse in dieser Wertaussage ist etwas kniffelig, denn es geht nicht um Prozesse im Allgemeinen. Gemeint sind hier Prozesse, die die Notwendigkeit menschlicher Interaktionen und Komplexitäten ersetzen sollen. Ich persönlich kenne Manager, die glauben, dass sie mit einem besseren Prozess keine hochqualifizierten Experten mehr einstellen müssten. Einer der großartigen Aspekte der derzeitigen agilen Systeme ist, dass menschliche Aspekte nicht nur aufgepfropft werden bzw. man nicht nur über die Bedeutung der menschlichen Aspekte spricht, wie das bei etablierten Projektmanagementsystemen häufig der Fall ist, sondern die menschlichen Aspekte in die Prozesse integriert.
Zusammenfassend lässt sich also Folgendes konstatieren: Prozesse, die menschliche Aspekte zu ignorieren oder zu ersetzen versuchen, sind schlecht, während Prozesse, die sich dieser Aspekte annehmen und diese in das System integrieren, gut sind.
Wertaussage 2: Funktionierende Software ist wichtiger als umfassende Dokumentation
Im Gegensatz zu der vorherigen Aussage, die für alle Projekttypen gilt, handelt es sich hierbei um eine spezifische Aussage für adaptive Systeme. Die Kernaussage ist, dass anstelle der Dokumentation im Vorfeld eines Projekts, die festlegt, was in einem Projekt passieren muss, funktionierende Software (Inkremente) erstellt und dann entsprechend angepasst wird.
Wertaussage 3: Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung
Jedes Projekt profitiert von mehr Zusammenarbeit mit dem Kunden. Bei adaptiven Systemen ist die Zusammenarbeit mit dem Kunden nicht nur wichtig, sondern geradezu notwendig. Der Kunde muss, während das Team kontinuierlich neue Anforderungen spezifiziert, ständig mit dem Team zusammenarbeiten, die Inkremente prüfen und dem Team Feedback geben. Anderenfalls ist eine Anpassung des Produkts nicht möglich.
Und Vertragsverhandlungen lieben wir natürlich alle