In the December meeting of Agiletuesday, our Munich Scrum group, we talked about the Crystal methods and we agreed to discuss V-Modell as a prominent example of a high-ceremony method next time. Next time, this is January 19th, 2009 and I want to contribute a short text I wrote a few weeks ago.

Scrum and the German V-Modell
V-Model is one of the high-ceremony low-trust document-centric project management methods. Why should anybody want to bother viewing it from an agile perspective?
The reason (aside from the model’s role in the German market) which might make curious is that the new version “V-Model XT” (XT for eXtreme Tailoring) claims to provide a variant with „agile fulfillment“.
After an overview on the V-Model I would like to assess in which degree the V-Model can be made “compatible” with a Scrum project.
The name “V-Model” refers to the V-model of the systems engineering process and defines a complex process framework with its reference documentation on 790 pages.
A reference documentation of the V-Model can be found at: http://v-modell.iabg.de/v-modell-xt-html-english/index.html. A nice visualization of the model can be found at: http://graffletopia.com/stencils/130.

History of the V-Model
V-Model goes back to the early 1990s, where its first versions were developed for the German military sector. Its newest version “V-Modell XT” dates from 2004 and is mandatory for German federal agencies.
Overall Structure of the V-Model
Previous versions had a strict division into sub-areas with a strict flow of activities and work products.
V-Model XT introduced more flexibility by describing Process Modules, i.e. the actual activity types that comprise the sub-areas. There are some core modules, others can be selected (“tailored”) as needed. Each module defines a Work Product, the Activity required to produce it and the Roles included in executing the activity.
The modules cover the areas

• project organization
• project planning
• risk management
• configuration management
• quality assurance and project state model
• problem and change management.

Projects are classified into Project Type, i.e. templates for typical combinations of process modules.
For each project type there exists at least one sequence framework for the modules included, the Project Execution Strategy which defines Decision Gates where corrective actions can be applied. One variant is the Agile System Development strategy which will be described later in this article.
V-Model defines a plethora of Decision Gates (more than 20), roles (31), work products (118), activities (89) – we will just skip the details.
Project Types
An example for a constellation of project types would be:

• Subject is the development of an embedded system
• Project roles are acquirer with multiple suppliers
• The acquirer defines an appropriate project type“system development (acquirer)”
• The suppliers define matching project types based on the template “system development (supplier)”

The selection of the project type is the first step to be done in a project.
Process Modules
A process module covers all parts concerning a particular task and can be extended or changed individually. The characteristics of a process module are

• Work Product: the results produced
• Activities: the tasks to be executed
• Roles: the roles included in executing the tasks as responsible person or contributor.
• Input dependencies: other modules this modue depends on if it is not marked as initial or external.

V-Model defines about 20 process modules with a large number of work products and activities.
Agile Project Execution Strategy
The “Agile” Strategy is described as a specific sequence of process modules and is described in the vocabulary of V-Model through process modules, decision gates and product flow. An iteration consists mainly of the following steps:

• Project proposal is prepared
• If the project is approved, a Project Manual and a QA manual are prepared, we reach the decision gate Project Defined. This can occur repeatedly after iterations.
• After evaluating these documents, decision gates Requirements Specified and Iteration Scheduled are reached

Next gates are

• System Elements Realized
• Detailed Design Completed – after documentation is finished; now the next iteration can be scheduled

After a final delivery the following gates are reached:

• Delivery Conducted – if a delivery of the increment is appropriate
• Acceptance Completed – after delivery is accepted

source: V-Model reference documentation

Possible Mapping to Scrum
There is very little overlap between this “agile” model and how Scrum structures activities. We can define the Iteration Scheduled gate as the start of a Scrum planning meeting and the end of a review meeting as Detail Design Completed (documentation is aside of System Elements Realized always an implicit part of the definition of done). Delivery Conducted, i.e. after a iteration result can be delivered, could be mapped to a release for the product owner.
The internal state transitions in an iteration can be mapped to a set of addition to the definition of done – Jim Schiel has presented a similar solution for the co-existence of scrum and ISO 9001 on the Stockholm Scrum Gathering in 2008.
This leaves us with the problem of the gate Offer Submitted, which is, unlike the next gate Contract Awarded, not iterative. The co-existence with Scrum works nevertheless, but only if the orders are coarse-grained enough.
In this case we can establish “Scrum in the small” where the product owner acts as a firewall to the overall process. I have developed in Scrum projects of this type and under ideal condition it can work. It puts however a high degree of tension on the product owner and an associated risk of project failure.