Skip to main content

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.


Craig Brown said…
Sorry Peter, I have to disagree. The V Model can be implemented at each sprint or even sprint backlog item level can't it?

It would have been written in the context of a waterfall world, but it is a useful framework for thinking through the testability of requirements and development work.

Personally I think it aligns perfectly with many quality practices within the agile collective.
Peter said…
Hi Craig,

Yes, it can be implemented within a sprint. I have seen teams do exactly that. I have also seen many teams employ higher performing strategies.

I agree with you that many ideas of the V-Model are valid. You'll be able to read about that tomorrow.

Particularly if you add 'test first', i.e. define the test before you write the code, then it works much better.

So my hope is that V-Model trained professionals will recognize known valid principles in the agile approach and thereby become more willing to try out the new stuff.

James Christie said…
Peter -one of the problems of the V Model is the way that it can mean different things to different people.

You are talking about the German government project management methodology, das V-Modell, which bears little resemblance to the much vaguer V Model that testers are familiar with. I don't think many people outside the German speaking countries are familiar with das V-Modell.

Unlike the exhaustive and rigorously defined V-Modell, the testing V Model is a loose concept. It can be useful in helping beginners think about the relationship between the requirements, coding and testing, but I believe that it is damaging if it encourages people to think that testing should be structured in the way that the V depicts.

I think that might explain the disagreement between Craig and yourself. I would agree with you that das V-Modell is rooted in the Waterfall, and I would agree with Craig that can be a useful, though superficial, concept for thinking about testing.

I wrote an article about the V Model that explained my concerns, and also highlighted the confusion caused by very different creatures having the same name.
Craig Brown said…
Excellent article James. Thanks for bringing it to my attention.
Peter said…
Hi James, thanks for pointing this out! I have updated this and the followup article to reflect this (for me) new information.

Thanks again!

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…