Seit dem agilen Manifest 2001 hat sich vieles geändert. Es gibt neue Kommunikationsplattformen wie Skype, webbasierte Kollaborationstools und die Cloud. Softwareauslieferungen erfolgen über das Internet mit minimalem Aufwand und in beliebig kurzen Zyklen etc. etc. Kaum denkbar, dass all das keinen Einfluss darauf hat, wie Softwareentwicklung erfolgreich gestaltet werden kann.

Neben der technischen Revolution hat sich auch die Softwareentwicklungsbranche völlig verändert. Immer noch gibt es die großen Produktlieferanten wie Microsoft, SAP u.a. und große Dienstleister wie accenture, Atos, CSC u.a. und Unternehmen die beides abzudecken versuchen wie IBM, HP u.a. Daneben gibt es allerdings einen neuen Typ von Unternehmen unterschiedlicher Größe, die Apps entwickeln und auf den Markt bringen und deren Geschäftsmodelle sich völlig von dem der klassischen Softwareunternehmen unterscheiden. Deren Vertriebsweg sind vor allem der App-Store von Apple sowie Google-Play, sie finanzieren sich nur zu einem relativ geringen Teil über Lizenzen und neue Releases folgen in ungleich kürzeren Abständen aufeinander als bei den „traditionellen“ Softwareunternehmen. Das Wasserfallmodell ist für diese Unternehmen jenseits jeder Relevanz, da sie typischerweise mit möglichst wenig Features so schnell wie nur möglich auf den Markt gehen. Christoph Keese zitiert in seinem Buch „Silicon Valley“ einen erfolgreichen Startup-Gründer: „Es geht darum, möglichst rasch ein möglichst gutes Produkt auf den Markt zu bringen. Das Produkt muss schlank sein. Es muss die Kernfunktionen enthalten, mehr nicht“.

Wenn man die Zusammenarbeit von Anwendern und Entwicklern als zentralen Erfolgsfaktor der Softwareentwicklung sieht wie es das agile Manifest tat, müssen die Regeln von 2001 heute neu geschrieben oder zumindest neu interpretiert werden.

Das Dogma von kleinen, autonomen Teams die tägliche Standup-Meetings nach einem streng geregelten Ritual abhalten, kann in weltweit agierenden Unternehmen nicht aufrecht erhalten werden. Zusammenarbeit von Teams, die auf unterschiedliche Kontinente verteilt sind und dazu noch unterschiedliche Zeitzonen stehen dem oft entgegen. Virtuelle Scrum-Boards, Webkonferenzen mit Screen-Sharing und Kollaborationsplattformen müssen genutzt werden.

Auch das Rollenbild muss flexibel gehandhabt werden, für komplexe Produkte wird die Rolle des Product Owners nicht von einer einzigen Person wahrgenommen werden können. Auch Elemente traditioneller Projektleitung wird man in Projekten mit hohem Risikopotenzial und mit unterschiedlichen Unternehmen, die daran beteiligt sind, nicht vermeiden können. Termin- und Budgetaussagen fließen nun einmal in Verträge ein, für deren Einhaltung jemand die Verantwortung übernehmen muss.

Fundamental ist das Kommunikationsproblem zwischen Anwendern und Entwicklern, das oft zu Themenverfehlungen führt. Es wird eine Implementierung ausgeliefert, die an den wahren Bedürfnissen der Anwender vorbeigeht. Es ist nun einmal so, dass erst in der Auseinandersetzung mit funktionierender Software  erkennbar wird, welche Funktionen tatsächlich einen Wertbeitrag für das Geschäft des Kunden leisten und welche bestenfalls nice-to-have sind. Will man mit neuer Technologie die Geschäftsprozesse oder gar das Geschäftsmodell verändern, gilt dies umso mehr, ohne agile Vorgehensweisen wird man hier nicht zum Ziel kommen.

Tragfähige Architekturentwürfe für große Anwendungssysteme mit zahlreichen Schnittstellen können nicht basisdemokratisch erarbeitet werden, es müssen also top-down- und bottom-up-Vorgehensweisen intelligent miteinander kombiniert werden. Water-Scrum-Fall ist ein lustig formulierter, jedoch absolut ernst zu nehmender Ansatz eines hybriden Vorgehensmodell. Am besten hilft hier meiner Meinung das bei uns zu wenig bekannte DSDM weiter.

Dass im Wasserfallmodell der Umfang fix und Budget sowie Zeitplan variabel sind während agiles Vorgehen das Budget und den Zeitplan fixiert und den Umfang variabel hält, macht agile Projekte für stark budgetgetriebene Unternehmen (und das ist nicht nur die öffentliche Verwaltung) leichter handhabbar.

Agile Projekte eignen sich nicht für Werkverträge, damit entstehen rechtliche Probleme wenn es um Nichterfüllung oder Mangelleistung in einem Projekt geht. Auch Haftungsfragen können nicht wirksam abgebildet werden. Durch geeignete Rahmenverträge und Fokussierung auf die vertragliche Regelung der Realisierungsphase kann dem gegengesteuert werden. Ein Patentrezept für den Erfolg agiler Projekte gibt es allerdings genauso wenig wie für andere Formen der Projektabwicklung.

PMI, das weltweit führende Standardisierungsinstitut für Projektmanagement misst agilen Methoden hohe Bedeutung bei. Der PMI Agile Certified Practitioner (PMI-ACP) ist mit weltweit ca. 7.000 zertifizierten Personen gegenüber dem Project Management Professional (PMP) mit über 600.000 Zertifizierten noch in den Anfängen, die Wachstumskurve zeigt aber steil nach oben.

Agile Methoden, dass kann ich aufgrund meiner eigenen Erfahrung und dem Erfahrungsaustausch mit anderen Projektmanagern gesichert behaupten, bieten in der Praxis bei richtiger Anwendung deutlich bessere Voraussetzungen für den Erfolg als traditionelle Vorgehensmodelle, die in der Planungsphase eine Sicherheit vorgaukeln, die am Ende sehr oft nicht eingelöst werden kann.