Krishan Mathis fasst in seinem Beitrag „Scrum and the German V-Model XT“ das Ergebnis einer Diskussion auf dem letzten Agile Tuesday in München zusammen. Der Beitrag enthält eine sehr lesenswerte Kurzfassung des V-Modell XT und geht auch auf die „Agile Durchführungsstrategie“ ein: „There is very little overlap between this ‚agile‘ model and how Scrum structures activities“. Die Aussage lässt sich durchaus auf die meisten agilen Verfahren übertragen.
Krishan kommt zu dem Schluss, dass man den Product Owner als „Schnittstelle“ zwischen den Welten „missbrauchen“ kann, aber nicht ohne eine Warnung: „It puts however a high degree of tension on the product owner and an associated risk of project failure.“

Ich denke, für alle agilen Verfahren ist die „mechanische“ Kopplung beider Welten über eine „Schnittstelle“ eine mögliche Lösung, nicht nur für Scrum. Man sollte sich dabei aber auch darüber im klaren sein, dass man sich damit auf sehr dünnes Eis begibt. Wird vom Auftraggeber das V-Modell XT verlangt, hat das normalerweise einen von zwei Gründen:

• Der Auftraggeber ist gesetzlich und per Ausschreibungsrichtlinie gezwungen, das zu verlangen
• Der Auftraggeber hat sich bewusst für ein hoch-zeremonielles Verfahren wie das V-Modell XT entschieden

In beiden Fällen ist der Schluss naheliegend, dass die interne Kultur des Auftraggebers so gestaltet ist, dass Mechanismen und Ideen des V-Modell XT zur Kultur passen. So kann zum Beispiel die Einhaltung von Vorschriften und unveränderten Verträgen wichtiger sein, als ein schneller RoI, selbst wenn sich das als projektgefährdend herausstellen sollte. Auch kann die Bereitschaft, individuell Verantwortung zu übernehmen, deutlich geringer sein, als zum Beispiel bei einem Startup.

Ist das der Fall, ist die Wahrscheinlichkeit hoch, dass weder Auftraggeber noch Auftragnehmer glücklich werden mit agilen Ansätzen. Der Wunsch, hinter einer V-Modell-Fassade agil zu arbeiten, sollte meines Erachtens also vom Auftraggeber ausgehen, und dieser sollte auch in der Lage sein, die notwendigen Entscheidungen zeitnah zu treffen — und später auch die Verantwortung dafür zu übernehmen. Zudem sollte man sorgfältig abgewogen haben, ob die Fassade wirklich sein muss, oder ein offener Ansatz möglich ist und man sollte sich ggf. auch mit Hilfe eines Spezialisten für Ausschreibungsrecht absichern und mit der zuständigen Innenrevision gesprochen haben.

Das klingt jetzt zwar alles wenig agil, aber man sollte sich auch im Klaren sein, dass die freundliche Gruppenleiterin, mit der man gerade verhandelt, wenig zu melden hat, wenn sich die Herrschaften des Rechnungshofes ankündigen. In diesem Sinne muss man sich nicht nur prozesstechnisch anpassen, sondern eben auch kulturell.

Aber um auch mal etwas positives zu sagen: Verglichen mit dem V-Modell 92 und 97 ist das V-Modell XT bereits ein riesiger Schritt in die richtige Richtung und hat bereits so manche Kritik an den alten Modellen aufgegriffen. Ich glaube, dass sich die Lücke in den nächsten Jahren weiter schließen wird, nachdem die Diskussion, ob agile Entwicklung überhaupt „echtes Software-Engineering“ sei zugunsten der agilen Verfahren ausgestanden sein dürfte.