Skip to main content

Moving forwards with V-Model

I recently worked with a VP of Quality Assurance.  His system needed high quality: it transported 10s if not 100s of Millions of CHF every day. It had to work and the consequences of it not working were horrendously expensive! He genuinely believed in the V-Model. Introducing the V-Model had substantially improved the quality of the system. His QA department was the last guardrail before the cliff.

In retrospect, I am not sure if his inspiration was the German government V-Modell, or the more general V Model.  In any case, the developers wanted to do Scrum and he wanted to preserve the essential aspects of the V Model which had enabled the level of quality they had achieved. How can he do that while moving forward in a Scrum context?

For him, three facets of the V Model were essential:
  1. Tester and developer roles should be separated ("4 eyes principle")
  2. Requirements should be matched with Acceptance tests
  3. A quality gate between QA and Production is essential to prevent poor quality code from entering service.
Applying the V Model mapped naturally to their organizational structure (roughly: Business, SW-Dev, QA, Production). This had improved the software from where it had been previously, but had caused substantial rivalry between the organizations, especially between Dev & QA:
A development manager was fond of telling people "75% of the time spent in the QA phase is not a about fixing bugs, but agreeing on the right version of the spec, the right interpretation of the spec, the right test data, etc. Most 'findings' aren't really findings, but misunderstandings."

The test manager responded: '3/4ths of the genuine findings do not get fixed before the system goes into production.' 
Both of these statements were correct. How can you fix this the problem? The short answer is for the stakeholders to agree on the acceptance tests before the developer starts to write the code. This is what Scrum helps you do.

Separation of tester from developer role

An side-effect of having a QA department do acceptance testing is that the Business people who defined the requirements are not the necessarily the people accepting the results (until it is put into production). So the tester has to interpret the spec -- possibly, but not necessarily the same spec that the developer is working to -- and this leads to differing interpretations. Who knows the answer? The customer, user or stakeholder: "Business."

Scrum does not say how to test. It does say that 1) Product Owner represents the interests of all the stakeholders (and is free to involve them directly when appropriate), 2) the Team has all the skills necessary to get to Done -- which surely includes analysis, coding and testing, and may include other skills, 3) that the Team is responsible for the Quality of its work, and 4) that the Product Owner and Implementation team must agree on a Definition of Done to ensure the quality of each feature as it is produced.

This definition often includes some form of pairing, e.g. Design Review, Code Review or Pair Programming or and independent test. Many teams automate the execution of their test suites. The discussions which occur in preparation of and during the sprint ensure all questions related to a feature get raised and captured in some form of acceptance test.

So adhering to the "4-eye principle" is ensured explicitly by the planning process and strengthened through the definition of done.

Requirements should be matched with Acceptance tests

The latest version of the V-Modell ("XT") was developed in 1997 and it has not been updated since. Therefore modern thinking about 'test-first' strategies, such as Test Driven Development, has not been incorporated into the V-Modell.

In Scrum, every entry on the Product Backlog represents a requirement and either is, or can be mapped to, an acceptance test. The corresponding acceptance test(s) are defined no later than the Sprint Planning Meeting, and probably somewhat earlier. The definition is moved to the front of the process, and the developers have a fixed target to work toward.

Quality gate between QA and Production

The Definition of Done is in essence an internal quality gate for the team. It is passed by every function that is completed in every sprint. Teams often include test automation in their definition of done, so that running, tested features in this sprint stay running and testing in future sprints.

I like to compare software production with auto production at this point. When Toyota has finished building a car, they do a quality check to make sure there are no defects. They don't expect to find any, but they check anyway. Why? Because it will be more expensive to fix it in the field, and they want to prevent the mistake from reoccurring.

In software it should be the same. The initial quality gate in Scrum is the definition of done, which is checked by the team.

So your teams work on improving their quality though automation and test first strategies. The definition of done always includes verifying the that the acceptance tests pass. At each Sprint Review, the Product Owner confirms that the implementation is doing what the stakeholders want.

If the team has achieved the level of quality which is possible through automated testing, then a relatively quick sanity check should be sufficient to ensure the system will work properly in production. There should be no question whether the features will meet the requirements; that has already been verified by the stakeholders themselves. (Actually achieving this level can be a substantial challenge and may take months or years to achieve - in the meantime you will have no choice but to do manual regression or integration tests).

So Scrum addresses all of the key points of his V Model while recognizing the chaotic, creative nature of software development. The organizational structure around the development organization may change, but happy users of the V Model will recognize many of their core principles in Scrum.

Update: Thanks to James Christie for pointing out that there are really two V-Models - the very specific German V-Modell (which was the subject of yesterday's article) and the vaguer 'V Model' which is familiar to most testers. For an excellent article on the history and context of the V Model(s), see The Dangerous and Seductive V Model.


Craig Brown said…
Thanks Peter. We are more or less in agreement.

Although scrum itself isn't proscribing 'four eyes' it is good practice isn't it, and scrum teams would be silly to ignore the learning of past teams.
Peter said…
Hi Craig, there are a lots of things that Scrum doesn't proscribe. Scrum says that you have to pay attention to quality (or 'doneness'), not how to do so. The How is up to you, and that leaves a lot of room to build on your own experience to do things which make sense ;-)

James Christie said…
Thanks for recommending my article.

I find this topic fascinating, as you might have guessed from the fact that I wrote that article.

Whenever someone mentions the "V Model" I ask "what do you mean by the V Model?" especially if they are attacking or defending it. Sometimes people disagree strongly then realise that in practice they would want to do the same thing. Their disagreement was about the terminology not actions.

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…