Die ersten Projekte waren klar dem Waterfall Modell zugeordnet, damals gab es ja auch nichts anderes. Aber schon damals machte es mir innerlich immer ein kleines Problem, dass bei diesem Vorgehen kleinere Verbesserungen, die auf dem Weg lagen, nicht eingebaut werden konnten, da das nicht im Lösungsumfang enthalten war. Klar lassen sich alle der Entwicklung nachgelagerten Prozesse so hervorragend planen, aber das Ergebnis leidet und die Beteiligten durchlaufen Frustrationsphasen. Mit Einzug von modernen, agilen Entwicklungsprojekten konnte der Wunsch nach “spontanen” Verbesserungen hervorragend adressiert werden.

 

Was aber, wenn die Entwicklung agil erfolgt und der Kunde strikt nach Wasserfall vorgeht? Hier muss eine Minimallösung für beide Seiten festgelegt werden, die auf jeden Fall ausgeliefert werden muss (MVP). Diese Lösung muss über entsprechende Sprints ein Gesicht bekommen und wesentliche Stakeholder auf Kundenseite werden herzlich zu den Sprint Reviews eingeladen um zu sehen wo man steht und um ggf. zu steuern. Hier können so Details geklärt werden, über die sich der Kunde bisher keine umfassenden Gedanken gemacht hat oder wo es Interpretationsspielräume im Konzept bzw. der User Story gab. 

 

Am Ende der Sprints zu Lieferung des MVP wird mit dem Kunden dann die nächste Planungsphase eingeläutet und man plant einfach das nächste Projekt, dass dann in einer Fortschreibung des MVPs besteht.

Über solch ein exemplarisches Vorgehen kann eine Brücke zwischen old-scholl und agil geschaffen werden. Die Lösungsmöglichkeiten sind aber vielfältig und müssen nicht immer diesem Ansatz folgen.