Ladies and Gentlemen, welcome to this evening’s fight between two heavyweight contenders. In the red corner we have V-model, defending champion and staunch fighter with stamina and in it for the long haul. In the blue corner we have the young upstart, Agile, contending for the title of best methodology with it’s ability to react, adapt and move quickly. Which one will win…
I’ve found that many conversations about development methodologies end up in a bout similar to this; a battle; a contest of which one is better.
The arguments go something along the lines of “V-model is so rigid, it’s just impossible to adapt to changing requirements”, “Agile is just for cowboys, an excuse not to write anything down”, “You spend most of your time in V-model writing documentation before writing any code”, “There is no traceability with Agile, you can’t ensure regulation compliance”, “V-Model is just old school, it doesn’t work in modern software paradigms”, “Agile doesn’t work for large complex projects”
These arguments seem so well defined and are the same time and time again, yet when researching v-model and agile, there is no one definition for either. In fact, you can read half a dozen definitions of each and they will be different.
I’ve been learning alot about V-model recently, and my views on this methodology have changed considerably. It turns out that the view of V-model being a rigid, inflexible, monolithic dinosaur of a methodology seems to have been largely forged by how it’s been implemented in the various large U.S. corporations. In fact, the definitions of V-model are diverse because it is not set in stone. So perhaps things are not as cut and dried as they first seemed.
As for Agile, if it can’t be used on large complex projects, how come the multi million dollar, highly complex F-22 software was developed using the Scrum agile methodology?
I venture to suggest that the two methodologies are closer than some would care to admit. In fact, Agile could be called the love-child of V-model and the desire to work in a more flexible way. V-model can be flexible, can be an adaptive approach. Agile can be a more deliberate, more structured approach.
So rather than thinking of them as separate methodologies, and rather than ‘choosing’ a methodology to use on a project, perhaps it would be better to decide how you want to work based on the context of the project, the client, the domain etc. You may very well find that a V-model structure helps to get testers in on the action very early in the project, and then Agile software development practices can be used to provide early feedback on minimal viable products. V-model can help to keep a project within scope, but does not mean everything needs to be defined up front. I could go on.
Don’t use a methodology for methodologies sake, use what’s right for your project, your team and your client… and don’t be afraid to change it. What’s right to use at the start of a project, might need changing as the scope or state of the project changes.
I used to be a very big believer in Agile development over everything else, but now I’m a believer in developing software in the most appropriate way. Perhaps I’m now methodology agnostic!