Eine Alternative zu Scrum bei Auftragsprojekten

Die Entwicklung im Auftrag mit Scrum

Von einem wirklichen Einvernehmen, wie man bei der Entwicklung kundenspezifischer Softwarelösungen vorgehen sollte, sind wir heute weiter entfernt denn je. Das hat damit zu tun, dass agile Softwareentwicklung nach Scrum tatsächlich nicht immer und nicht überall der richtige Weg ist. Man sollte sich immer vergegenwärtigen, vor welchem Hintergrund Scrum in den 90ern erfunden wurde: als die optimale Organisationsform für eine eigene, begrenzte Entwicklermannschaft für ein eigenes Produkt oder Online-Angebot. Wenn „time to market“ das wichtigste Anliegen ist, dann ist es sinnvoll, so schnell wie möglich eine erste Version auf den Markt zu bringen bzw. live zu gehen, um dann mit dem vorhandenen Personal in vergleichsweise kurzen Zyklen immer wieder neue, verbesserte Versionen nachzulegen. Und das immer so weiter – Softwarepflege bis in alle Ewigkeit.

Leider passt aber all dies nicht so recht auf den Fall einer typischen Auftragsentwicklung, bzw. wenn überhaupt, dann erst in der späteren Pflegephase. Warum? Bei einer Auftragsentwicklung will man so schnell wie möglich und so kostengünstig wie möglich eine fertige Software geliefert bekommen, die alles enthält, was bestellt wurde. Zwischenlieferungen sind nur Zeit- und Geldverschwendung.

Es ist zwar richtig, dass die meisten Auftraggeber gern Zwischenstände sehen möchten, um neue Erkenntnisse in die Entwicklung einbringen zu können, und um sicher zu sein, dass man auf dem richtigen Weg ist. Aber jeden Monat eine voll getestete, aber nutzlose Version abnehmen zu müssen, das ist sicherlich nicht im Interesse des Auftraggebers. Bei einer Auftragsentwicklung muss man normalerweise immer mit einem fixen Budget auskommen. Daher bevorzugen Auftraggeber oftmals klassische Festpreisprojekte. Eine Scrum-Entwicklung aber ist quasi ein Blanko-Scheck für den Auftragnehmer. Selbst wenn jeder einzelne Sprint als separater Festpreis vereinbart wird: Für den Auftraggeber wird das oft zu einer endlosen Folge von immer wieder neuen Versionen mit immer wieder neuem Gang zum Budgetverantwortlichen.

Es mangelt fast immer an einem kompetenten Product Owner, der alles im Blick hat, der das gesamte Projekt versteht, der sämtliche Anforderungen der Anwender aufnehmen und in die IT-Sprache übersetzen und zudem auch noch die unendlich vielen Wünsche vernünftig priorisieren kann. Für den Gründer eines Start-ups mag das für sein Projekt noch klappen, aber in einer großen Organisation wird man kaum jemanden finden, der diesem Anspruch wirklich gerecht wird. Wenn aber jemand zwischen Anwender und Entwickler steht, der von allen Beteiligten am wenigsten versteht, worum es eigentlich geht, dann ist dieser Ansatz von vornherein zum Scheitern verurteilt.

Viele IT-Chefs berichten, dass Scrum-Projekte, sofern sie denn überhaupt jemals fertig wurden, mindestens das Doppelte bis Dreifache gekostet und doppelt bis dreimal so lange gedauert haben, als wenn man sie zum Festpreis vergeben hätte. Wer sich diesen Overhead leisten kann, für den mag Scrum durchaus sinnvoll sein, um das Produkt gut an der Realität reifen zu lassen.

Es gibt noch einen weiteren, einen technischen Grund, der es nahelegt, Scrum für Auftragsentwicklungen zumindest kritisch zu betrachten, denn die meisten ausgeschriebenen Business-Anwendungen sind im Kern Datenbankanwendungen. Es liegt in der Natur der Sache, dass Datenbankanwendungen so aufgebaut werden müssen, dass das zugrundliegende Datenmodell gewissermaßen das Fundament der weiteren Entwicklung ist. So wie man kaum ein Haus nach Scrum entwickeln kann, indem man ein Zimmer nach dem anderen plant und dann jeweils das Fundament um ein paar Meter verlängert, so kann man auch nicht ein Feature nach dem anderen einbauen, ohne dabei das Datenmodell und somit das gesamte Projekt dermaßen zu beeinträchtigen. Ein ständiges Umbauen des Datenmodelles, was ganz typisch für Scrum-Entwicklungen ist, führt zu teilweise absurden Mehraufwänden und/oder zu einer schlechten Architektur der Anwendung.

Das Phasenagile Vorgehensmodell als Alternative

Um dieses Problem zu lösen und dennoch ein Maximum an Agilität zu ermöglichen, wurde das Phasenagile Vorgehensmodell entwickelt. Hier wird das Haus nicht von links nach rechts oder von innen nach außen gebaut, sondern so wie es eigentlich üblich ist: von unten nach oben.

Daraus ergibt sich ein optimales Vorgehensmodell für Low-Code-Entwicklungen, in geordneten Projektphasen von wohldefiniertem Umfang und Inhalt, und zugleich so agil wie möglich in den einzelnen Phasen. Wie diese Phasen genau aussehen, mag von den konkreten Rahmenbedingungen, vom Geschäftsfeld des Anbieters, und vielleicht auch von den konkreten Eigenschaften der jeweils eingesetzten Low-Code-Plattform abhängen. Für Datenbankanwendungen in einem kostenbewussten und termingebundenen Projektumfeld erweist sich ein 5-stufiges Phasenmodell als optimal:

1. Initialisierung
2. Datenbasis
3. Programmrahmen
4. Fachmodule
5. Finalisierung

Für die fünf Phasen ist jeweils etwa der gleiche Zeitbedarf zu veranschlagen. Phase 1 betrachtet das Gesamtprojekt, also auch all das, was erstmal nur im Backlog steht und vielleicht eines Tages noch beauftragt wird. Nur so ist es möglich, die Grundarchitektur und das Datenmodell des Systems auf eine hinreichend solide Basis zu stellen.

Anschließend wird in Phase 2 das Fundament geplant und gegossen. Das heißt, dass alle Entitäten des künftigen Gesamtsystems bereits mitberücksichtigt und zueinander in die richtigen Beziehungen gesetzt, aber auch alle Schnittstellen in die Außenwelt und andere technische Grundaspekte mit einbezogen werden. Das heißt aber nicht, dass man schon alle Datenbanktabellen final attributieren muss. Es geht eher um das große Ganze. Und um die Frage, wie bereits beim Datenmodellieren die künftigen Anwender einbezogen werden, wo diese doch angeblich nur in Prozessen, aber nicht in Datenstrukturen denken können. Aber weit gefehlt: Man muss nur wissen, wie man das macht. Ganz sicher nicht, indem man mit Anwendern ER-Modelle an der Tafel diskutiert. Man muss mit geeigneten technischen Mitteln die Datenstrukturen „lebendig“ und verständlich machen – idealerweise anhand echter Kunden- oder realitätsnaher Testdaten.

Danach geht man weiter, von Etage zu Etage, von Phase zu Phase, und es wird immer agiler. Bei aller Freiheit, die jeweiligen Details immer weiter auszuprägen, geht dies stets immer nur in genau der jeweiligen Phase. Im Anschluss wird sozusagen die Tür zugemacht und spätere Änderungen sind nur noch in Ausnahmefällen zulässig.

Die Hauptarbeit liegt in Phase 4, in der unter Umständen mehrere Design-Thinking-Teams gleichzeitig aktiv sind. In den Anfangsphasen sind die Informatiker etwas mehr gefragt, während später im Projekt verstärkt die Citizen Developer aktiv werden, also Projektmitwirkende, die mindestens ebenso tief im Fachlichen stecken wie in der IT. Wie viele Phasen ein Projekt haben sollte, hängt von den verwendeten Softwaretechnologien, dem Charakter des Projekts und vielen anderen Randbedingungen ab.

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, von der ersten bis zur letzten Woche. Das ist genau der Zeitraum, nach dem man bei der Arbeit mit Low-Code-Plattformen jeweils hinreichend viel Neues zur Diskussion stellen kann, sodass die Besprechungs- und Doing-Aufwände in einem sinnvollen Verhältnis stehen und sich die Reisebelastung der Mitarbeiter 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.

Low-Code-Entwicklungen mit dem passenden Vorgehen

Es kommt stets auf die konkreten Rahmenbedingungen an, welches Vorgehensmodell für ein Vorhaben 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 Phasenagile Vorgehensmodell zwei sinnvolle Alternativen.

Das Phasenagile Vorgehensmodell ist zwar nicht an bestimmte Entwicklungsmethoden gebunden, eignet sich aber sehr gut für die Arbeit mit Rapid-Development-Werkzeugen und Low-Code-Entwicklungsumgebungen. Low-Code-Plattformen erlauben eine Softwareentwicklung ohne oder fast ohne Programmierung, lediglich durch interaktive Konfiguration in einer Art „Cockpit für Business Developer“. Dies verleiht den Entwicklern nicht nur eine ungeahnte Entwicklungsgeschwindigkeit, es ist auch hervorragend dazu geeignet, die künftigen Anwender direkt in den Entwicklungsprozess mit einzubeziehen.

Das heißt natürlich nicht, dass man zwingend vor Ort entwickeln muss, oder dass die Anwender permanent den Entwicklern über die Schulter schauen würden. Eine Möglichkeit wären wöchentliche Workshops mit Besprechungen und Sofortoptimierungen der laufenden Arbeitsstände direkt am Bildschirm, und zwar ganz bewusst im direkten Dialog direkt zwischen Entwicklern und Anwendern.

Für die Durchführung der Arbeitsworkshops der interdisziplinären Teams empfehlen sich die Prinzipien des „Design Thinking“, und zwar in allen Projektphasen. Ganz wichtig dabei ist, dass die Projektleiter beider Seiten (Auftragnehmer und Auftraggeber, bzw. Fach- und IT-Abteilung) mehr Moderatoren als Owner der zu entwickelnden Produkte und Projekte sind.

Wenn dies erfolgreich umgesetzt wird, dann eröffnet es den Anwendern ein deutliches Mehr an Einflussnahme-Möglichkeiten als es bei einer Scrum-agilen Entwicklung jemals möglich wäre. Der Anwender ist viel dichter an den eigentlichen Entwurfsprozessen dran, und neue Ideen lassen sich viel schneller, teils sofort, auf ihre Umsetzbarkeit und Tauglichkeit prüfen. Wenn es das Budget erlaubt, gerne auch mit Giebeln und Türmchen, ansonsten eher zweckmäßig nüchtern.

Aber wie auch immer, ob mit oder ohne Pflichtenheft, ob Festpreis oder nach Aufwand, ob mit oder ohne Giebel und Türmchen: Ein gutes und kooperatives Projektmanagement ist bei allem stets das Entscheidende.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Weitere Informationen zum Thema Low-Code finden Sie unter https://www.scopeland.de.

Karsten Noack hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.