It’s dead! You will hear people say. It’s an abomination, they cry. It should be banished to the past, they demand.
Now… what’s so terrible? Maybe you’ve heard of it before: the V-Model (interestingly, Wikipedia has two entries for it). It’s widely known and used in software-related product development.
So what is the V-Model?
It’s a model on how to systematically approach software (or embedded devices) development.
The idea is that one starts out at the top-left of an imagined V with the highest-level requirements, usually direct demands of the customer. These are then progressively broken down into more detailed specifications, architectures etc.
The actual development, the coding, circuit design and whatnot take place at the bottom of that V.
Then, as one ascends the right-hand side of the V, verification takes place: every specification will be tested to prove that it is satisfied. This usually happens layer-by-layer, corresponding to the specifications at that level on the left-hand side of the V. Concretely, one often sees unit tests, integration tests and acceptance tests.
So what – we’re doing Agile anyway
Some people think that since Big Design Up Front is going out of fashion, this whole discussion about the V-Model is moot. This is not the case, however.
Let me explain.
One of the tenets of Agile is the sprint: a fixed time-box with a predefined scope. Before beginning a sprint, you come up with a list of features you want to implement over its course. Then once the sprint is underway, you will not deviate from this plan. The idea is to have a planned feature completely designed, implemented and tested to a production-ready state by the time the sprint is over.
Now think about this for a moment: you have design, implementation and testing for a fixed-scope item. Does this look like a V to you? It does, doesn’t it.
Agile has just broken down the development from having one huge V to a bunch of mini-Vs that hopefully fit the chosen iteration size.
This makes these discussions amusing sometimes: some proponents of Agile attack the V-Model as being a problem, while unwittingly still using it. We can debate the merits (or not) of Big Upfront Designs, but that is a different debate.
This sounds like a good idea – why are people complaining?
Honestly: I’m not sure.
There is a supposed conflict to the Agile way of doing things.
My feeling is that a lot of people are attacking it as supposedly being merely a re-shaped waterfall model. This supposition is incorrect. And that’s a very good thing, as the Waterfall model was explicitly presented as an example of a flawed process that couldn’t work. It’s ironic that plain Waterfall was apparently used in practice anyway.
Some people look at the V in the V-Model, take its shape at face value and assume there is no feedback loop. And maybe some diagrams out there don’t make that feedback loop explicit – that’s really a mistake in the presentation of the V-Model.
Clearly it’s meant to be used with feedback (which makes it… an O model?). If you test, obviously you will do something about the issues you find. Otherwise, why bother: if you don’t react to the test results, what’s the point in testing?
So, clearly the V-Model incorporates feedback loops. Once an issue has been spotted in testing, it will be reported back to the left-hand side of that V for analysis, and eventually make its way back down and back up the V, until subsequent re-tests show that the issue is satisfactorily resolved.
Conclusion
Seeing as Agile and “traditional” practitioners alike still very much use the V-Model (and for good reasons), it’s wise to think about it hard, and make sure you use it deliberately and in a way that’s most suited to you.
I believe that making levels of detail explicit, and using them to guide your thinking and design process, is a very useful thing. It also makes testing very natural, as things on the right-hand side will have a clear counterpart on the left-hand side. It would be a smell if they didn’t.
The only warning I’m going to give is that it’s easy to go overboard with tools such as the V-Model, and create an overly complicated system. Maybe having experienced that is where some of that resistance comes from.
But I claim you are using some kind of V-Model anyway, whether you are aware of it or not. So make this fact explicit and deliberate, and benefit from the clarity this brings.