The Hub blog
Scrum vs V-model: which method should you adopt?
Do you know the difference?
Scrum what? V-model?
The Scrum method and the V-model are two project methodologies that emerged in the 1980s-1990s. The V-model became widespread in the 1980s, whereas the Scrum method appeared in 1995.
These two methods are both ways of building a product, but in completely different ways.
You’re probably thinking: what on earth is she on about?
Don’t panic!
Today, the Dgitags team will try to answer all your questions:
What is the V-model? What is the Scrum method? What sets them apart? Is one more effective than the other?
If you’d like to find out more about these two methodologies, read on below.
Let’s go!
An introduction to the V-model
The V-model is a management method that spread in the 1980s. It was introduced to address a number of problems regularly encountered in so-called Waterfall methodologies.
How the V-model works
The project team starts with the first stage, “requirements analysis and feasibility”, and finishes with the last stage, “acceptance testing”. However, unlike waterfall methods, the V-model allows you, for example, to rework the architectural design if the integration tests fail, or to rework the specifications if the validation tests don’t pass.
So when you reach a stage and can’t complete it properly, you have to rework the stage that led to it.
You can therefore go back, even though there’s no notion of iteration.
What’s more, you have one project team per line.
Good to know:
The letter “V” comes from the fact that the model pairs each development phase with its corresponding validation phase. The left arm of the “V” represents the tasks related to designing and developing the system, the right arm the associated quality assurance measures. The product implementation phase sits at the centre between the two arms, between the development and quality assurance phases.
Source: https://www.ionos.fr/
Advantage of the method:
The main advantage of this method is that it delivers economies of scale by tackling the entire project scope in one go.
Drawbacks of the method:
- Lack of communication: each project stakeholder plays their part in turn, but they never all play together, and they communicate mainly through documents.
- Lack of flexibility: to move from one stage to the next, the previous one must be finished. This can lead to schedule overruns, and therefore cost overruns.
- Product obsolescence: projects of this type often take quite a long time. In the meantime, the need may have changed, so the final result will no longer match the initial requirements.
- Lack of feedback: if the documentation related to the product’s design is incomplete, the final product won’t fully meet the client’s needs, and the method doesn’t provide any opportunity for interim checks.
The risks created by the V-model encouraged the emergence of new, so-called Agile methods, such as Scrum.
An introduction to the Scrum method
The word Scrum refers to the scrum in rugby. Indeed, this method focuses on team spirit and the drive to move forward together towards the same goal.
This method appeared in 1995 and is very popular today. Scrum is built on 3 main pillars: transparency, inspection and adaptation. It’s described as an iterative and incremental methodology.
In the Scrum method, the product is developed in time-boxed iterations (called sprints). The aim is to keep the client at the centre of the product by trying to involve them regularly throughout the project’s delivery cycle.
There are three key players:
- The Product Owner: has a complete vision of the product,
- The Scrum master: makes sure the project runs smoothly and keeps the method on track,
- The Scrum team: develops the product.
The Product Owner defines the product backlog. This backlog is a prioritised list of the product’s target features. As the project takes shape, the list can evolve according to needs. Once the backlog is in place, the first sprint can begin.
During a sprint, the Scrum team and the Scrum master review the product’s development and start each day with a “scrum” during which they go over the day’s objectives. Sprints are generally set every 2-3 weeks.
At the end of each sprint, the client and the Product Owner assess the partially deliverable product, either to approve it or to point out changes to be made, which are added to the product backlog.
Advantages of the method:
-
A final product that will be close to the client’s expectations, since changes and needs are taken into account throughout the development process.
-
Easier communication thanks to regular sprints and to the Scrum Master, who is there to facilitate the link between all stakeholders.
Risks of the method:
-
Lack of documentation: as this method adapts to the client’s needs, the project changes quite often. Some information can therefore get lost or not be properly updated. Once the project is finished, you need to pay attention to the information handed over to the maintenance teams. It must be up to date.
-
Misinterpreting the Scrum method and the “daily scrums”: this method can prove complex to understand. It is, after all, very different from traditional management methods. You therefore need to make sure teams understand it properly. What’s more, if the method is poorly explained, daily scrums will be seen as a way of policing people.
Not to be confused!
Agile is a development methodology based on an iterative, incremental approach. Scrum is one of the implementations of the agile methodology.
Now let’s move on to a more in-depth comparison of these two methods.
“V-model” vs “SCRUM”
Product vs Project
One of the differences between these two methods is this: the V-model is a project management method, whereas Scrum is a product management method.
In the Scrum method, the product is at the centre of the project. The product imagined at the start of development won’t be the product delivered 6 months later.
Throughout the project’s development, the Scrum team presents its progress during sprints. Clients can give feedback and change certain aspects of the project if they’re not convinced. The team takes this feedback into account to improve the product in the following iterations. Given that it’s virtually impossible to have conceived the perfect product from the outset, the product won’t be exactly the one imagined at the start of the project.
With the V-model, you often have to wait for final acceptance testing before considering any changes to the product. A new cycle will be needed to implement changes that improve the product.
So with the V-model, the product may not be deliverable at the end of the cycle, whereas with Scrum, involving the client each time makes it possible to deliver a product that has already undergone many changes and will be deliverable.
Scrum vs V-model: documentation
The Scrum method can prove a little too vague on certain points, such as documentation and technical quality. Scrum teams tend to skip documentation and technical quality in order to deliver the product as quickly as possible. But this reasoning is a mistake.
Agility isn’t about delivering the product as fast as possible; agility means regularly delivering very high-quality products, which is something completely different.
Wanting to deliver as quickly as possible while neglecting quality documentation — that is, writing it as the project evolves — is ultimately anti-agile, since the maintenance teams who later take over the project risk being lost if the documentation isn’t kept up to date.
The V-model doesn’t really have this problem, since each project stakeholder communicates mainly through the documents handed over after each stage. The documentation is therefore often well maintained.
Scrum vs V-model: a question of era?
In the V-model, there are clearly defined roles for specification, architecture, development, testing and so on. Today, developers are less and less willing to accept this way of working. They much prefer being active contributors to the product, well beyond development.
Scrum, on the other hand, fosters collective intelligence, which is not at all the case with the V-model. That’s why developers often identify more with the Scrum method.
So it’s also a question of era: the V-model was very popular in the 1980s because it offered a model perfectly suited to its time.
Scrum vs V-model: flexibility of the model
In the age of Uberisation, Scrum offers real flexibility in creating the product and evolving it. Scrum makes it possible to change course very quickly and avoid ending up with an obsolete project at go-live.
The acceleration of time-to-market is now a problem for some companies, as needs evolve quickly, new needs emerge, and companies have to stay on their toes to respond as well as they can.
With Scrum, you won’t deliver the complete final product faster, but you will deliver the minimum acceptable product to launch well before the expected final product. You can therefore test the product quickly and improve it.
Scrum vs V-model: the right to make mistakes
The notion of error is very important in Scrum. Teams learn from their mistakes and can correct course from the very next sprint.
Being able to make quick corrections in Scrum makes it easier to accept mistakes. What’s more, they’ll have a minor cost. Making a mistake in the V-model is far more costly.
For example, with the V-model, a functional error will only be spotted at acceptance testing. This can lead to a project that’s obsolete on delivery, or one that doesn’t really meet the initial needs.
With Scrum, such an error would have been spotted quickly and corrected very fast.
Scrum vs V-model: company culture
Even if the Scrum method seems more effective, it’s not always suited to every type of project and every type of company.
First, a company can’t become fully agile overnight. It takes time and good support to implement a Scrum method. To build an effective change strategy, it’s important to understand where the organisation stands and to define the transition phases according to its maturity and level of readiness.
Indeed, applying agile methods such as Scrum requires a high degree of team empowerment, since teams have to relearn a certain way of working. In a traditional waterfall or V-model environment, teams align with a particular function, such as development or testing, and rely on processes and templates, but without seeing the bigger picture. The problem is that the agile approach requires flexibility, close collaboration between the different teams, and communication. It’s a big change.
That’s why some traditional companies (for example in their management style) won’t manage to embrace this new “liberated company” model, as their often paternalistic corporate culture is too deeply ingrained. A change as profound as this risks being doomed to failure.
Company culture must therefore align with agile methods for them to work. The culture must be ready to embrace agility.
The right questions to ask when choosing between the two methods
To choose between these two methodologies, you need to ask yourself the following questions:
1/ Am I able to mobilise a team that can take an active part in my project (to define needs and test developments)? If so, opt for the Scrum method.
2/ Do I fully master the need the project must meet, and am I able to describe exactly how it should work, with certainty and in full? If so, opt for the V-model.
The Scrum method is therefore better suited to complex projects with little visibility, since it brings more flexibility and adaptability to requested changes, as well as better risk management.
The “V-model” makes it easier to frame an industrial project, for which the client has a very precise vision of what they want (for example: requirements, a detailed schedule and anticipated risks).
Conclusion: Scrum vs V-model
While V-model projects were, in the 80s/90s, a genuine evolution of waterfall to address the problems encountered, Scrum does exactly the same thing years later, offering a method even better suited to today’s context.
Scrum will probably face the same kind of comparison with future project management methods. These methods will probably be better suited to the context in which our future companies will operate.
That’s the end of this article. Yes, already… Don’t worry, we’ll be back soon with even more content :)
The Dgitags team nonetheless hopes you found this article interesting and that it taught you a few things about these two methodologies.
Within the Tags community, our teams are used to working with agile methods. Don’t hesitate to reach out to them if you have any questions or would like to benefit from our services.
Our services:
- Our developer studios
- SEO by Donutz
- SEA by Donutz
- A network of freelancers, experts in their field (design, web marketing, product)
See you soon!
Appendices
Benefits and risks of the new “liberated company” methods (such as the Scrum method):
Source: “Management of organisations” course, Audencia BS
Sources: