March 31, 2016
V-Model vs Scrum, Who Wins?
Why is it important to know the difference between V-Model and Scrum?
The V-Model and Scrum provide great promise to projects who adopt them. However, if either methodology is implemented with partial understanding of it, it can be harmful for the project in the long run.
The V-model provides guidance to test managers and other project leaders involved in software projects, on how to be successful in realizing their projects. This model is pretty popular amongst test managers and some also call it the verification and validation model.
There is also an agile way of working for test managers, one of it being Scrum. It is important to know the difference between the various agile techniques such as Scrum and the V-Model because it is often confused to be similar. This confusion could have damaging effects on projects in terms of time, money and resources.
The V-Model has several practical benefits for a test manager such as diligence in implementing all testing process steps, a high quality end product, testing preparation occurring in tandem with development, and good overall documentation for testing. Unlike waterfall methodologies, V-Model encourages testing preparation to occur in parallel with requirements, design, and development phases and this ideology may be the only similarity between the V-Model and agile forms of testing.
However, V-Model can be rigid and less flexible in comparison to agile methodologies. The Scrum framework is built so that the team can be prepared to handle change but the V-Model has a different purpose geared towards increasing productivity of the testing processes. In this sense, the rigidity of the V-Model can conflict with the agile culture in the organisation and may cause unnecessary tensions and confusion. Hence, as a test manager it is best to know clearly the fundamentals of both the V-Model and Scrum, before having your team adopt one of them.
The fundamentals of V-Model and Scrum
- The History of V-Model: The V Model has a long history and legacy. The earliest concept and use of the V-model originated in Germany which then was called the Das V-Modell. It was the official project management methodology used by the German government in the early 1990s. This model is roughly equivalent to PRINCE2 but being more relevant to software development. It was later adopted by the UK and US governments but the scope is used for a rather narrower purpose of systems development life cycle.
- Basics of V-Model: Visually speaking the V-Model is nothing but a diagrammatic representation of a systems or software development life cycle. It summarises the main verification and validation preparation steps to be taken in conjunction with the actual implementation of the system or software.
The left side of the “V” in the diagram represents the concept, requirements creation, architecture design, and detailed low level design. The right side of the “V” represents the integration of the parts of the system, verification, validation and operational maintenance of the system. In this model the verification is done against the technical terms and requirements and the validation is done against the usability and user experience.
- The History of Scrum framework: The Scrum framework was invented by Jeff Sutherland and Ken Schwaber in the 1990s. The Scrum framework is based on the agile manifesto principles, which forms the foundation of all agile methodologies. Some of the principles that form the basis of Scrum may have distant inheritance to the Japanese Lean models which were used for automobile manufacturing. Some other models like Kanban may have been an inspiration for Scrum to come into existence.
- Basics of Scrum: The word Scrum comes from a rugby term, where the teams huddle up before going on to the field. The Scrum framework has lots of similar cross-functional team huddles within it. In the Scrum world there are only 2 fundamental types of roles. A chicken or a pig. A chicken is a role where the person is not completely committed to the work but may still be a part of a team or an effort. A pig is a role where the person is completely committed to the team or effort.Additionally, 3 key players in the Scrum framework are product owner, Scrum master and the Scrum team. The product owner is the single wringable neck responsible for the end product, the Scrum master is responsible for ensuring that the Scrum framework is being followed and impediments are being removed. The Scrum team is a cross-functional set of people who actually do all the work for all the lifecycle areas. A tester plays a significant role in the Scrum framework, and closely works with the fellow team members as a part of the same unit.
V-Model or Scrum, who wins?
A fair way to find out who wins is by doing a clear comparison between them. Let’s break down the comparison into the following 7 attributes:
- Return on investment (ROI)
- Culture, product quality
- Customer satisfaction
- Employee satisfaction.
I have seen time and time again that productivity directly depends on the people doing the work, irrespective of what framework is being followed. However, if you compare the V-Model and Scrum, the Scrum model has a slightly higher chance of winning. I’ll explain my reasoning with a simple example.
Let’s say a test manager is tracking ten features his team is testing for a project and the team is in the middle of verifying the implementation. Five features have been verified and certified by the testers and five remain to be tested but the team discovers that the requirements have slightly changed affecting all the features. Triggered by this change, the development team will have to update the code, which will affect all the ten features.
Now, if you pass this scenario through the V-Model, the requirements documentation will be updated, the design may have to be updated and the code will definitely be updated. Next, the testing team will retest the five features that it had already tested and then test the other five remaining features, which means the testing team spent 50% more time in testing due to the change.
If you pass this same scenario through the Scrum framework, it won’t result in productivity loss because the team is testing throughout the cycle and may be constantly making adjustments to the code. In fact, it will facilitate the team to adapt more easily to the change. Since the batch size of work is less in Scrum, the chances of rework affecting the productivity are pretty low.
Going back to the same example the ROI will be higher in Scrum because of its relatively flexible and light nature of its framework. Scrum is the clear winner here.
Since V-Model is just a model, it does not explicitly encourage any type of culture so it may not be fair to judge it based on culture. The V-Model may intrinsically spread a message of rigidity by the way the model is designed but I believe it can still be adopted in agile cultures as long as it is understood clearly.
Since Scrum is based on the agile principles, it clearly spreads a culture of collective ownership of the end result. This attribute is subjective, and different organisations may prefer different cultures, so I think this attribute deserves to be a draw between Scrum and V-Model.
If you strictly go by the model and framework language and rules, the V-Model wins. Some may disagree with my reasoning but to be fair the V-Model lays explicit emphasis on validation and verification of product quality.
All the rigid test preparation and verification checks that are enforced in the V-Model are not mentioned in the Scrum framework, making V-Model the winner by the book. However, Scrum may still earn a silent victory due to its flexible nature. I say that because Scrum users may claim that they may still use the V-Model techniques within their Scrum framework, which is certainly a possibility.
Scrum clearly wins here, and so do all agile methodologies. However, note that flexibility comes with a price of more frequent check points. The more change that occurs, the more checks you will have to put. It is important to maintain a balance between rigidity and flexibility, and the Scrum framework allows the Scrum team members to reach that balance over time.
It really depends on who the customer is to judge based on this attribute, but I believe Scrum wins here with a slight advantage due to its customer focussed framework. However, in a government organisation which may get audited several times a year by external agencies, the V-Model would be the more viable option.
The V-Model enforces enough documentation to ensure quality of the verification and validation leaving no stone unturned. However, the Scrum model lets the testers in the team come up with their own models.
From my experience I have noticed that people working in agile environments, like Scrum, feel more satisfied by their work compared to those working within more rigid frameworks.
The rigid hierarchy and process may make employees lose motivation because in the back of their mind they know that the chances of an idea or change to be implemented is minimal. Scrum gives more freedom to employees on how to do their work, encourages change, and gives the employees tools to handle change better.
- The V-Model and Scrum can seem very similar but they are different at many levels. It is important to understand the basics of each method before applying them in a project to avoid any process related pains down the line.
- The V-Model regiments the testing processes to take place alongside other activities in the lifecycle, right from project initiation to project closure.
- In comparing the V-Model and Scrum, Scrum takes the upper hand in productivity, ROI, flexibility, customer satisfaction and employee satisfaction.
- The V-Model definitely may have a better record in overall product quality in terms of testing activities due to its regimented testing process.
We can compare the V-Model and Scrum all we want but at the end of the day an experienced test manager will realize that it’s not just the process that matters. What is important to note is how these 2 methods can complement each other and help teams build a better product.
It is definitely very important to know the strengths and weaknesses of both these processes, but in the long run it really does not matter which process wins or loses. What really matters is whether the people adopting and implementing the process are successful or not!