Design Thinking als Grundprinzip

Wenn es heute möglich ist, Computerprogramme in Echtzeit vor den Augen der Anwender, oder gar mit diesen gemeinsam live am Bildschirm umzubauen, dann ist der Scrum-typische Monatsrhythmus der agilen Softwareentwicklung eindeutig zu langsam. Eine direkte Interaktion zwischen Anwendern und Entwicklern, etwa um gemeinsam optimale (das heißt für die Anwender sinnvolle und zugleich technisch gut umsetzbare) Lösungswege zu finden, ist nicht vorgesehen. In diesem Sinne ist Scrum eindeutig nicht agil genug.

Außerdem stellt sich in der Praxis immer wieder die Frage, ob es diesen einen allwissenden Product Owner überhaupt gibt. Wissen nicht die einzelnen Fachanwender selbst am besten, was sie brauchen? Die Projektleiter sollten sich daher nicht so sehr als Owner des entstehenden Produktes sehen, sondern mehr als Moderatoren zwischen Anwendern und Entwicklern, um unter den gegebenen Rahmenbedingungen, wie etwa begrenztes Budget oder restriktive Zeitvorgaben, dennoch zu einem optimalen Ergebnis zu kommen.

Das wesentlich bessere Medium als ein Backlog sind regelmäßige Design-Thinking-Workshops, und dies nicht nur in der Anfangsphase eines Projekts, sondern über den gesamten Projektzeitraum hinweg. Design Thinking steht für interdisziplinäre Zusammenarbeit in gemischten Teams, für Offenheit und Kreativität, und zugleich für deutlich weniger Tool-Gläubigkeit. Die Tools des Design Thinking sind keine Computerprogramme, sondern Papier und Bleistift, Whiteboards und Stehtische, mit und auf denen man gemeinsam Bildschirmentwürfe malen oder Abläufe skizzieren kann. Und die Offenheit, immer wieder alles zu hinterfragen, frei nach dem Prinzip "Ist das wirklich das, was Sie brauchen?". Als Diskussionsgrundlage haben die Teilnehmer hier stets die laufenden Arbeitsstände auf dem Bildschirm: keine Sprints, keine fertigen Module, sondern laufende Arbeitsstände - unfertig und ungetestet, aber realitätsnah in der Handhabung und mit mehr oder weniger echten Daten.

Das Projekt horizontal, nicht vertikal zuschneiden

Auf der anderen Seite ist Scrum aber auch zu agil, weil es der Versuchung Tür und Tor öffnet, die Dinge in der falschen Reihenfolge zu tun. Für typische Datenbankanwendungen ist es sinnvoll, in einer frühen Projektphase zumindest die Grundstrukturen des Datenmodells verbindlich und endgültig festzulegen, um ein kostenintensives Ändern der bereits fertigen Programmteile zu vermeiden, wenn neue Use Cases Einfluss auf das Datenmodell haben. Zudem lassen sich so gleich zu Beginn Altdaten anonymisiert übernehmen oder realitätsnahe Testdaten generieren, und auf diese Weise wirklichkeitsnäher und unter Last entwickeln.

Zudem legt das Low-Code-Prinzip mit seinem enormen Implementierungstempo und seinem 98%-Ansatz nahe, bereits zu Projektbeginn die Dinge zu identifizieren und zu initiieren, die vielleicht doch programmiert werden müssen, und die sonst als zu spät gestartete 'Langlaufende Tasks' die Endtermine gefährden könnten.

Schließlich lässt sich noch vor der Erarbeitung der konkreten Inhalte und Bedienabläufe der komplette Programmrahmen mit Benutzerverwaltung, Layout und UUX-Richtlinien im Vorfeld entwickeln, bevor man sich mit den Anwendern in die Einzelheiten der Programme vertieft. Auf diese Weise werden die später zu besprechenden Arbeitsstände plastischer und realitätsnäher, was die besonders wichtige kreative Zusammenarbeit mit den späteren Anwendern erheblich vereinfacht. Außerdem kann man dann die etwas umfangreichere Arbeit an den eigentlichen Inhalten noch etwas weiter nach hinten schieben, was die Planbarkeit verbessert und die Aktualität erhöht.

Lesetipp: Stakeholder-Analyse - So identifizieren Sie Projektbeteiligte

Das phasenagile Vorgehensmodell

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. Die einzelnen Phasen kann man etwa wie folgt definieren:

1. Initialisierung

2. Datenbasis

3. Programmrahmen

4. Fachmodule

5. Finalisierung

Für die fünf Phasen ist jeweils etwa der gleiche Zeitbedarf zu veranschlagen. Die Hauptarbeit aber liegt in Phase 4, in der unter Umständen mehrere Design-Thinking-Teams gleichzeitig aktiv sind. In den Anfangsphasen sind etwas mehr die Informatiker gefragt, während weiter hinten im Projekt verstärkt die Citizen Developer aktiv werden, also Projektmitwirkende, die mindestens ebenso tief im Fachlichen stecken wie in der IT.