Noch im vorigen Jahrtausend habe ich einen Vortrag zum Thema „Rapid Application Development“ und „Fast Prototyping“ gehalten. Da das agile Manifest erst 2001 veröffentlicht wurde, gab es den Begriff „agil“ noch nicht als Standard, aber genau das war gemeint.
War ich gegen oder für solche Vorgehensmodelle? Ehrlich gesagt habe ich das schon damals als eine Frage des „Wie“ und nicht des „Ob“ gesehen.
Lange Zeit wurde „agil“ mit Misstrauen betrachtet und man musste argumentieren, warum man so vorgehen will. Mittlerweile hat sich das komplett gedreht, in vielen Organisationen ist „agil“ der Standard und „Wasserfall“ ein No-Go. Ich habe die lustige Erfahrung gemacht, dass ich bei ein und demselben Projektsponsor einmal mein agiles Vorgehen tarnen musste und 5 Jahre später war agiles Vorgehen seine Vorgabe. Ob aus tiefster Überzeugung, wage ich zu bezweifeln, das überbordende Mikromanagement in diesem Projekt spricht eindeutig dagegen.
Aber zurück zum Titel: Ich halte das Vorgehen nach dem Wasserfallmodell für ideal und höchst erstrebenswert. Ein umfassender Plan zu Beginn der Arbeit, eine Schritt-für-Schritt-Realisierung, bei der das Ergebnis jeder Phase die Grundlage für die nächste Phase bildet und am Ende der ursprüngliche Plan bis auf wenige Change Requests erfolgreich umgesetzt wurde.
Aber auch hier gilt mit Bertolt Brecht „Doch die Verhältnisse, sie sind nicht so!“ Denn sie sind VUKA (volatil, unsicher, komplex, ambivalent).
Oder gibt es sie doch noch, die Projekte, die sich für das Wasserfallmodell eignen? Ich bin seit vielen Jahren vorwiegend in der öffentlichen Verwaltung tätig, aber auch vor Covid-19 habe ich nie erlebt, dass die Voraussetzungen für ein klassisches Wasserfallmodell gegeben waren. Agile Vorgehensmodelle sind also auch in einer als stabil geltenden Branche ein Muss.
Was mich allerdings zunehmend irritiert, ist die dogmatische Herangehensweise an das Thema Agilität, die sich in den letzten Jahren breit gemacht hat. Typisch dafür: Egal worum es geht, wir machen Scrum! Anforderungen gibt es nur noch als User Story, auch wenn vielleicht eine Entscheidungstabelle oder ein Set von Testfällen präziser wäre. Noch seltsamer finde ich es, wenn technische Anforderungen an Schnittstellen krampfhaft in User-Stories umgeformt werden. Ich muss allerdings die Urheber von Scrum vor ihren Fans in Schutz nehmen, denn der Scrum-Guide hat inzwischen das Wort „User-Story“ gestrichen und durch „Backlog-Item“ ersetzt. Anscheinend haben viele Scrum-Fans nach ihrer Zertifizierung aufgehört, sich weiterzubilden.
Das Vorgehen in einem Projekt muss dem Erfolg dienen. „One size fits all“ gilt auch für Vorgehensmodelle nicht. Scrum hat viele Vorteile, passt aber nicht immer. Manchmal ist Kanban (Lean) oder XP die bessere Variante. Und man kann auch Elemente kombinieren, wir sind keiner reinen Lehre verpflichtet. Hybrid wird meist für die Kombination von klassischem Vorgehen (Wasserfall) mit agilen Methoden verwendet, gilt aber meiner Meinung nach auch für die Kombination von agilen Methoden. Gerade XP wird meiner Meinung nach zu Unrecht vernachlässigt: Pair Programming, Refactoring, Test Driven Development sind sehr nützliche Methoden, die in jedem Setting eingesetzt werden können.