Das V-Modell: Wasserfall oder agil?

Immer wieder wird das V-Modell als Wasserfallmodell bezeichnet und somit als nicht agil definiert.

Wahr ist: Das V-Modell ist eine Projektmanagementmethode und wir können jede Methode agil betreiben, oder eben auch nicht. Es ist natürlich auch wahr, dass wir in der Pharma das V-Modell oft sehr „unagil“ und als Wasserfall verwenden. 

Aber nur weil wir unseren Geländewagen ausschließlich auf der Straße fahren, heißt das ja nicht, dass er auch im Gelände eine gute Leistung abrufen kann. Ehrlicherweise bin ich sogar der Meinung, dass das V-Model insbesondere am Anfang ein sehr guter Ansatz ist, um agiler zu werden. Die Begriffe sind den Kollegen und Inspektoren/ Auditoren bereits vertraut und so müssen wir zu einer geänderten Arbeitsweise nicht auch noch neue Worte lernen. 

Das V-Modell als Antichrist der agilen Methodik?

Woher kommt es jetzt, dass das V-Modell als Wasserfall bezeichnet und damit quasi der Antichrist der agilen Methodik ist? 

Das kommt primär aus der sehr statischen Verwendung in der Planungs-Phase, also quasi des linken Arms des V. Hier kommt oft die Aussage ins Spiel, dass bei komplexen Systemen zu Beginn noch gar nicht alle Anforderungen exakt definiert werden können – aber auch das ist nur teilweise richtig. Es wird mit dem Argument, dass die Anforderungen noch nicht „perfekt“ sein können, gar nicht erst begonnen und gedacht, dass das mit Scrum oder einem anderen agilen Ansatz besser zu erledigen wäre. 

Anforderungen müssen nicht perfekt sein!

Fakt ist, egal mit welcher Methode, das Problem bleibt dasselbe. Wir müssen uns also zunächst davon lösen, dass Anforderungen ab der ersten Version perfekt sein müssen. Sobald wir das einmal akzeptiert haben, lässt sich auch das V-Modell plötzlich agil verwenden.   

Schauen wir uns mal an, wie dies aussehen kann: 

Schritt 1: Benutzeranforderung

Wir, als Anwender, schreiben auf, was wir von der gewünschten Lösung erhoffen. 

Wenn wir Lücken und Unklarheiten sehen, schreiben wir auch das auf. 

Was zumeist schon sehr früh klar ist, ist der Pain, der Schmerz, der behoben werden muss und dieser muss eindeutig definiert werden. 

Schritt 1a: Start der Entwicklung

Jetzt bereits fängt die Entwicklung an.  

Ist das ok? Warum nicht? 

Wir beginnen eine erste Version zu erstellen! 

Schritt 2: Funktionale Spezifikation

Mit den ersten Ergebnissen beschreibt der Lieferant jetzt, wie die Aufgabe erfüllt werden kann. 

Auch hier wird es noch Lücken und Unklarheiten geben. Die entstehenden Lösungen werden direkt dokumentiert und Anweisungen erstellt, wo sie benötigt werden. 

Schritt 3: Design Prüfung / Testen

Jetzt vergleichen wir als Anwender den geplanten Ansatz mit dem, was wir wollten und werden dabei Abweichungen feststellen. 

Schritt 3a: Alles Auf Anfang

Alles, was wir gelernt haben, lassen wir in die nächste Version der Benutzeranforderung einfließen und das Spiel beginnt nun von vorne. 

 Auf diesem Wege iterieren wir uns Zyklus für Zyklus an unsere optimale Lösung heran. Sobald wir an diesem Punkt sind, müssen wir jetzt nur noch die Lösung über VAL auf PROD ausbringen und auf dem Weg dorthin formal testen. Mit allem, was zuvor gelaufen ist, wird dies jedoch kein Problem mehr sein! 

Fazit: Das V-Modell kann auch agil sein und ist gerade für Pharma ein guter Startpunkt

Für mich ist klar, auch das V-Modell kann dynamisch und agil angewendet werden. 

Wenn wir und unser Team uns mit diesem neuen V-Modell weiterentwickeln, können wir im nächsten Schritt schauen, dass wir unsere Arbeitspakete kleiner machen und dadurch nicht in großen Abständen eine Vielzahl an Features deployen, sondern im Optimalfall mit jeder Iteration dem Kunden eine verwendbare Verbesserung liefern. 

Mit chaotischen Grüßen,
Christof Layher