“Wieso machen wir eigentlich Agile?”
“Weil wir es noch nicht sind!”
Laut dem Branchenindex “CHAOS Report” der Standish Group werden global weniger als 30% aller IT- und Softwareprojekte erfolgreich, sprich: “in time & in budget” abgeschlossen. Mehr als 50% erfüllen einen der beiden Parameter bei Projektabschluss nicht, die verbleibenden rund 20% scheitern zur Gänze. (The Standish Group)
Die Gründe für das Scheitern sind vielfältig, werden jedoch mehrheitlich in mangelnder Flexibilität, zu langen Entscheidungsfindungsprozessen, unfokussiert adressiertem Change Managament und unklaren Anforderungen verortet. (PMI)
Wenn man den CHAOS Report genauer betrachtet und zwischen konventionell bzw. agil umgesetzten Vorhaben unterscheidet, wird offenbar, dass Projekte, die mit agilen Methoden (oder zumindest Hybridmodellen) durchgeführt werden, zu 39% erfolgreich abgeschlossen werden, wohingegen diejenigen, die mit konventionellem Projektmanagement abgewickelt werden, nur eine Erfolgsquote von 11% aufweisen. Bei den gänzlich gescheiterten Projekten ist der Unterschied sogar noch deutlicher (9% agil, 29% waterfall).
Agile to the rescue!
Die zentralen Aspekte und Grundlagen der Agilität lassen sich mit den folgenden Aussagen zusammenfassen:
“Agile is about working smarter, rather than harder. It’s not about doing more work in less time: it’s about generating more value with less work.”
“In an Agile organization, self-organizing teams are continuously providing new value for customers.”
“Agile enables organizations to cope with continuous change. It permits them to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous.”
(Steve Denning)
But why not … you know … more conventional?
Das Cynefin-Framework (Dave Snowden, 1999) typologisiert vier Systemcharakteristika (Simple bzw. Obvious, Complicated, Complex und Chaotic) mit den jeweils zugrunde liegenden Eigenschaften und wie die daraus resultierenden Herausforderungen am besten gemanagt werden können.
Sobald ein Projektkontext – unabhängig von der Branche – eine hohe Dynamik aufweist, Abhängigkeiten und Anforderungen oft erst im Zuge der Umsetzung offenbar werden, Ursache/Wirkung-Zusammenhänge nicht klar nachvollziehbar sind und Erkenntnisse aus der Vergangenheit obsolet sind, ist ein erfolgreicher Abschluss mit konventionellem Projektmanagement in time und in budget selten bis nie erreichbar.
Factum est: Software Development ist hinsichtlich grundlegender Rahmenbedingungen und Eigenheiten so gut wie nie simple/obvious, zuweilen complicated, fast immer complex, gelegentlich auch chaotisch.
Die vermutlich vielversprechendsten Antworten auf diese Herausforderungen liefern Agile Methoden und das entsprechende Mindset.
Sie unterstützen Organisationen maßgeblich dabei, in der vorherrschenden VUCA-World valueorientiert planen zu können, die intrinsische Motivation der MitarbeiterInnen zu fördern, niemals den Kundenfokus aus den Augen zu verlieren und schlussendlich schnell und hochqualitativ Software zu liefern.
Im Agile Manifesto: liest sich das wie folgt:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Siehe auch: “Principles behind the Agile Manifesto”
“Be agile or not be agile. There is no do.”
Yoda
Wenn in einer Organisation damit begonnen wird, nach agilen Methoden/Frameworks zu arbeiten, agile Praktiken sinnvoll zum Einsatz zu bringen, agile Prinzipien zu etablieren und die agilen Werte zu leben, bestehen gute Chancen, das agile Mindset nachhaltig in der ganzen Organisation zu entfalten.
“Our greatest weakness lies in giving up. The most certain way to succeed is always to try just one more time.”
Thomas A. Edison