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.

Comments

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.

Cheers,
Peter
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. http://www.clarotesting.com/page11.htm
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…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…