Here is an article for all those who wish to understand the difference between Scrum vs V-model. For a lot of people the answer is obvious but for others the differences are not entirely clear.
The V-model in a few words
The V-model was a very popular project management method 20 years ago; it became popular in the 80s. It was not always well applied. Here is the cycle required to complete a V-model project:
This method v-model was very popular in the past. It brought obvious answers to the big problems encountered with the “waterfall” projects.
The team carries out the project by going from the first step “needs analysis and feasibility” to the last step “recipe” in a fairly traditional way. However, unlike the waterfall methods, the V-model proposes to rework the detailed design if the unit tests are not valid or to rework the specifications if the validation tests do not pass.
We are certainly on a system close to the waterfall concept but the V-model broke codes long imposed by projects in waterfall method. V-model allows to correct at different levels as the picture above shows.
The Scrum in a few words
Scrum is a method said “agile” that appeared in 1995. It become very popular for 10 years. A lot of people believe that agility is the scrum; but it’s obviously not the case.
The Scrum bases its operation on 3 main pillars: transparency, inspection and adaptation. We are talking about an iterative and incremental methodology.
In scrum, the product is developed by iteration of time (called sprints). The method brings the customer constantly to the center of the product by trying to intervene him regularly in development.
Scrum vs V-model
Scrum is 100% product
To begin, I’ll tell you that the V-Model is a project management method while the Scrum is a product management method. Are you seing see the difference?
A well applied Scrum bases its energy on the product itself. The product thought at the beginning of development will not be the product delivered in 6 months … Why?
At the end of the iteration (2 weeks for 80% of Scrum teams), the Scrum team will invite key users and stakeholders to come and see the finished work so that they can give it interesting feedbacks. The team will consider these to improve the product in the next iterations.
Knowing that it is almost impossible to have thought of the perfect product from the start, the product will not be totally the one that they had imagined at the beginning of the project.
In the V-model, we have to wait for the final recipe to consider product modifications; a new cycle will be needed to review a lot of improvements.
When we have a final product identical to the imagined product in a V-model, the product may not be deliverable; in Scrum, bringing regularly the customer to intervene on the product, we will deliver a product that will have already known many modifications (useless things removed and improvements added).
The V-model will have to wait for the final product phase + improvements to consider putting the product into production. The scrum allows to have the product in production for a while.
Moreover in Scrum, the product in production will be regularly updated (every 2 weeks or more); that’s why we say that Scrum accelerates the time-to-market.
Development speed in identical theory (scrum vs v-model)
I think that it’s important to remember it; some companies sell agility as a way to develop a product 4 times faster … It’s obviously a mistake to think that.
As you can see in the previous schema, we will not have the same product after 6 months, but the developers will not deliver more either.
The only phenomenon that I noted at certain moment but is only temporary and will not be in 10 years: the motivation of developers on some Scrum projects increase sometimes by the fact of using this fashionable work method; this will temporarily increase the productivity of the team … The phenomenon would be the same if another project management methodology became fashionable in a few years.
You would consider this last case as particular; you have to really consider that the speed of development is potentially very close.
Scrum sometimes too evasive
Scrum has the defect today to be a little too evasive on some subjects like documentation and technical quality. If the Scrum is deliberately evasive on these points without denying them, many teams take advantage of this to go beyond the documentation and technical quality to deliver as soon as possible…
This is a very big mistake, we don’t want to deliver everything as quickly as possible with agility; the agility want to deliver regularly products of very high quality which is very different.
If we want to deliver as quickly as possible by omitting a quality documentation (written progressively) and an irreproachable technical quality is not agile.
The Scrum loves communication
We see it regularly, the role of developers in Scrum has changed. We don’t talk about a developer but about a developer team. The Scrum pushes to collective intelligence which is not the case in the V-model.
In the V-model, we have well defined roles for specification, architecture, development, testing … Today this way to do is less and less accepted by developers; they appreciate much more to participate in the build of the product beyond development. The new generation that is very difficult to manage, prefer this position.
This is not a criticism of the V-model that proposed a model totally adapted in its time.
Flexibility as an axis of acceleration?
The Scrum offers a real flexibility in the creation of the product and its evolution. The phenomenon Uber change the vision of the companies; everything can be change very quickly. Scrum can be help the companies to have the capacity to change fast enough the functionalities of the product.
If before the problem did not exist, today it’s clear that the acceleration of this time-to-market is essential for a large number of companies including the largest French companies that have the reputation of being totally drowned in their processes.
We will not deliver the complete final product faster with the Scrum but we will deliver the minimum acceptable (MMF) to launch the product before the expected final product (V-model). We can therefore test the product quickly and improve it as the previous schema showed.
The right to error
As Alan D. emphasized on Linkedin, the notion of error is very important in Scrum. Teams learn from their mistakes in Scrum and they can rectify the trajectory from the next iteration.
As we can do corrections very quickly in scrum, we can accept easier our mistakes. They will have an insignificant cost. The same error in the V-model can be extremely expensive.
For example, in a V-model, the functional error will only be seen at the time of the recipe; we could even find that the project was obsolete or that it did not respond at the initial needs.
In Scrum, we would have been seen quickly this issue and would have been rectified as soon as possible.
Conclusion scrum vs V-model
If the projects in V-model were in the 80/90, a real evolution of the waterfall to address the problems encountered, the Scrum does exactly the same thing 20 years later by proposing a method more adapted to the current context.
Maybe in the future, we will compare Scrum and a future project management methods. These methods will be more adapted to the context in which our companies will be in the future.
It is quite possible that this break created by the V-model compared to the classic waterfall has been a source of inspiration for agile methods like Scrum.
The v-model will disappear in some years? Do you still use v-Model?
2 Trackbacks / Pingbacks