Bevor ein IT-Projekt losgeht, sollte man sich ein paar grundlegende Fragen stellen:

• Ist das in den 90er Jahren entwickelte Scrum-Vorgehensmodell noch das richtige und agil genug für die kommende neue Generation von Softwareentwicklungsmethoden?

• Sollte man Agilität neu denken, und wenn ja, dann wie? Vor dem Hintergrund eines entschlackten und wiederbelebten Wasserfallmodelles vielleicht?

• Oder sollte es bei künftigen Projekten in eine ganze andere Richtung gehen?

Wann ist agile Softwareentwicklung nach Scrum sinnvoll?

Die Vorteile von Scrum sind hinlänglich bekannt. Der Zeitraum von der Definition fachlicher Vorgaben bis zu deren Produktivsetzung wird von mehreren Jahren auf einen oder einige Monate verkürzt. Das allein ist ein großer Gewinn, der viel mehr Freiheitsgrade in der IT-Unterstützung der Fachbereiche eines Unternehmens ermöglicht. Wenn man genau hinschaut, dann ist die agile Softwareentwicklung nach Scrum aber nur eine vom Product Owner gesteuerte Aufeinanderfolge kleiner Wasserfallmodell-Projekte, in denen man sich von Ausbaustufe zu Ausbaustufe einer Software bewegt. Eigentlich ist es mehr ein agiles ProjektmanagementProjektmanagement als agile Entwicklung im engeren Sinne. Alles zu Projektmanagement auf CIO.de

Das Modell ist optimal zugeschnitten auf die selbstständige Entwicklung der eigenen Kernsoftware, beispielsweise einer Online-Plattform. Es ist ideal, um so schnell wie möglich mit einer zunächst überschaubaren Minimallösung produktiv zu gehen, und diese dann mit dem verfügbaren Personal schrittweise im Monatsrhythmus weiter auszubauen. Sehr gut geeignet ist Scrum auch für die laufende Weiterentwicklung fertiger Software im Rahmen eines konstanten Softwarepflegebudgets. Im Backlog werden die Anpassungswünsche gesammelt und dann, nach Priorität und Machbarkeit priorisiert, in die laufende Weiterentwicklung eingetaktet und jeweils in eine der nächsten Versionen der Software eingebaut.

Kombiniert mit einer modernen DevOps-Organisation kann man so seine IT merklich auf Trab bringen. Und es entspricht sehr gut dem laufenden Erkenntnisgewinn aus dem Betrieb der vorherigen Versionen. Zumindest wenn die Kosten keine Rolle spielen, kann dies aus Managementsicht der richtige Weg sein, und aus Sicht eines Personentage verkaufenden IT-Dienstleisters allemal. Nach Aufwand bezahlte Scrum-Projekte sind insbesondere für den Auftragnehmer von Vorteil, da risikolos und gut planbar.

Gibt es ein verbessertes Wasserfallmodell?

Geht es hingegen um die Neuentwicklung einer komplexen Softwarelösung, womöglich als Festpreisprojekt in einem Auftraggeber-Auftragnehmer-Verhältnis, liegen die Dinge anders. Niemand braucht jeden Monat eine funktionsfähige, aber allzu rudimentäre Programmversion, die ohnehin noch nicht einsetzbar ist. Der Monatsturnus steht zudem der Abarbeitung umfangreicherer Arbeitspakete im Weg.

Da nicht eindeutig zugeordnet werden kann, ob der Product Owner ein Vertreter der Fachabteilung, der IT-Abteilung, des Auftraggebers oder des Auftragnehmers sein soll, denn beides passt nicht optimal in die reale Welt, sind die Erfahrungen mit extern vergebenen agilen Entwicklungsvorhaben sehr durchwachsen. Wenn man genau weiß, was man will, und eine optimale und termingerechte Umsetzung wünscht, dann wäre das Wasserfallmodell eigentlich ideal - wären da nicht die altbekannten Probleme eines überbordenden Formalismus und unzureichender Aktualität, und vor allem das Stille-Post-Phänomen, welches die Nutzeranforderungen auf dem langen Papierweg teilweise grotesk verzerrt, so dass manchmal regelrecht am Bedarf vorbei entwickelt wird.

Lesetipp: Methodik in der Softwareentwicklung - Agil versus Wasserfall

Die Frage ist, ob und wie der vernünftige Grundansatz "Erst denken, dann handeln" in die agile Welt der Low-Code-Softwareentwicklung übertragen werden kann. Iteratives Prototyping allein, wie es beispielsweise im V-Modell-XT der Öffentlichen Verwaltung festgeschrieben ist, genügt hierfür definitiv nicht. Entscheidend für ein verbessertes Wasserfallmodell ist vielmehr, die Nutzeranforderungen viel direkter und schneller an die Entwickler heranzutragen, idealerweise im direkten Dialog. Dies aber wiederspräche der Grundstruktur klassischer Projektentwicklung mit vorgeschalteten Konzeptionsphasen - lange bevor die Programmierer ins Spiel kommen. Ineffizient ist dies allemal, da der Aufwand, die Anforderungen detailliert genug aufzuschreiben oftmals weit höher ist als der, sie mit einer hochentwickelten Low-Code-Plattform umzusetzen.

Für normale Projekte, bei denen sich die konkreten Anforderungen immer erst dann herauskristallisieren, wenn man schon was auf dem Bildschirm sieht, ist der vorgelagerte Aufwand eher ein Hemmnis als ein Vorteil, und erhöht zudem unnötig die Projektkosten. Also dann doch lieber agil - aber wie genau?