Scrum and V-Modell

One the participants from my last in-house course (at a bank) found that I was unfairly grouping the V-Model with “waterfall.” So let’s look at what is the difference between Scrum and the V-Model, see where the two come into conflict, and see where they can complement each other.

Update: It turns out this comparison is not as simple as I thought – there are actually two V-Models: a German government project management methodology, das V-Modell and much vaguer V Model that testers are familiar with. In researching this, I landed on the German government version, not realizing that there are really two versions of it. The following discussion is related to the German government model. Thanks to James Christie for pointing this out!

Scrum is a simple, team-based framework for solving complex problems. Its roots are in product development. It assumes that solving complex problems (like creating a software product or system) is a creative process, which by definition, cannot be defined in advance. This class of problems requires an empirical approach, with much interaction and feedback between the developers, users and stakeholders in the project. Therefore Scrum says nothing about how to do the work, but defines a few roles, rituals and artifacts to ensure effective communication.

The V-Modell is “designed as guidance for planning and executing development projects…. It defines the results to be achieved in a project and describes the actual approaches for developing these results. In addition the V-Modell specifies the responsibilities of each participant. Thus, the V-Modell describes in detail, ‘who’ has to do ‘what’ and ‘when’ within a project.”

A key feature of the V-Modell flow is the Decision Gate, which indicates “a milestone in the project sequence, where the current state of the project has to be evaluated. For every decision gate, the V-Modell defines a quantity of products which must be submitted in state Finished…”

So looking at these descriptions, I must say, V-Modell looks pretty Waterfall to me: a defined approach, with clearly defined phases and strong gatekeepers between the phases.

So philosophically, Scrum and the V-Modell are on different planets:

Scrum = empirical

V-Modell = defined

Often this phase based approach is reflected in the organizational structure. Requirements phase comes from Business, Implementation from Development, Test from QA, and Deployment from Operations. Each group of course has its own Vice President, which is helpful for the cooperation… not!

If they are so different, is there value in the V-Modell and how can a V-Modell practitioner so a future for himself in a Scrum managed environment? I’ll look at this question tomorrow.