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

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…

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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …