Der agile Festpreis
Das Phasenmodell mit ausgeprägtem Design Thinking ist zugleich auch der vermutlich beste Weg, um agile Festpreisprojekte zu ermöglichen. Um einem Ausufern der Benutzerideen entgegenzuwirken, sollten die Fachanwender und die Entwickler geeignete und zugleich bezahlbare Lösungswege gemeinsam erarbeiten und budgetkonform aushandeln. Die Projektleiter beider Seiten wirken bei Bedarf kompromissfördernd und mäßigend auf ihre Kollegen ein, da sie am gemeinsamen Projekterfolg gemessen werden. Bei Bedarf werden zusätzlich Plus-Minus-Listen geführt, über die Mehr- und Minderaufwände verrechnet werden können.
Entscheidend für den Projekterfolg ist dabei die strikte Planung der Design-Thinking-Workshops, und dass die Projektleiter effektiv durchsetzen, anstehende Entscheidungen auch wirklich zu treffen.
Das "Immer-Dienstags-Prinzip"
Für Low-Code-Projekte hat sich für die Design-Thinking-Workshops ein Wochenturnus als optimal erwiesen, und zwar über die gesamte Projektlaufzeit hinweg. Das ist der Zeitraum, nach dem die Beteiligten bei der Arbeit mit Low-Code-Plattformen jeweils hinreichend viel Neues zur Diskussion stellen können, sodass die Besprechungs- und Doing-Aufwände in einem sinnvollen Verhältnis stehen, und sich die eventuelle Reisebelastung externer Dienstleister in zumutbaren Grenzen hält. Zwar nehmen je nach Projektphase teils andere Personen an den Meetings teil, aber dennoch ist es sinnvoll, sofort zu Projektbeginn zwischen Auftragnehmer und Auftraggeber dafür einen festen Wochentag zu vereinbaren, wie beispielsweise jeden Dienstag. Das reduziert den Organisationsaufwand, und alle Beteiligten können besser planen.
Die instantane Entwicklungsmethodik
Wenn für den Auftraggeber nur das bestmögliche Ergebnis in möglichst kurzer Zeit zählt, kann es sinnvoll sein, die technisch mögliche Flexibilität von Low-Code-Produkten bis an die Grenzen auszureizen. Dies gilt vor allem dann, wenn die Aufgabenstellung zu Projektbeginn noch unklar ist, wodurch eine systematische Anforderungsanalyse weder im Vorfeld, in bestimmten Projektphasen, noch in der laufenden Fortschreibung eines Backlogs unmöglich ist.
Dann wird fast durchgängig vor den Augen der Endanwender und gewissermaßen auf Zuruf entwickelt. Das bedeutet, dass der Entwicklungsprozess zu großen Teilen durch spontane Eingebungen der Anwender gesteuert wird. Wenn die Technologie in der Lage ist, die Probleme abzufangen, die durch Try and Error zwangsläufig entstehen, dann liefert dieses Verfahren den unschätzbaren Vorteil, eine Anwendungssoftware schrittweise immer mehr an das anzupassen, was tatsächlich gebraucht wird. Hier macht es Sinn, zuerst über Datenstrukturen und Inhalte nachzudenken und danach über Prozesse und Programmoberflächen.
Nachteilig ist, dass Projekte bei instantaner Entwicklungsmethodik faktisch nicht kalkulierbar sind, und deshalb schwerlich mit fixem Budget oder gar als Festpreisprojekte aufgesetzt werden können. Instantanes Vorgehen erfordert einen finanziellen Spielraum. In der gesamten Kosten-Nutzen-Bilanz kann die instantane Vorgehensweise aber durchaus die wirtschaftlichste Methode sein, und sie kann bei guter Zusammenarbeit der Projektleiter beider Seiten für die Fachbereiche zu den besten erzielbaren Ergebnissen führen.
Wasserfall oder Scrum oder phasenagil?
Alle drei Vorgehensmodelle haben ihre jeweilige Berechtigung, und es kommt auf die konkreten Rahmenbedingungen an, welches am besten geeignet ist. Während das klassische Wasserfallmodell an sich gut und richtig, aber für Low-Code-Entwicklungen eigentlich zu langsam ist, sind das schon etwas in die Jahre gekommene Scrum-Konzept und das neuere phasenagile Vorgehensmodell zwei sinnvolle Alternativen - zwei Ansätze zur agilen Softwareentwicklung, die unterschiedlicher nicht sein könnten.
Während Scrum für die Eigenentwicklung von Softwareprodukten und Onlineangeboten, sowie für die kontinuierliche Verbesserung vorhandener Software als besser geeignet erscheint, ist das phasenagile Konzept viel besser auf budget- und termingebundene Neuentwicklungen ausgerichtet und ermöglicht agile Festpreisprojekte. In bestimmten Konstellationen, insbesondere bei etwas kleineren Projekten oder abgekoppelten Modulen bzw. Microservices von überschaubarer Größe mit relativ offenem Budget, macht es durchaus auch Sinn, noch einen Schritt weiter zu gehen, und gänzlich instantan zu entwickeln - eine Vorgehensweise, die ohne moderne Low-Code-Technologien kaum möglich wäre. (bw)