1. Home
  2. Blog
  3. Software Development
  4. Agile or V-Shaped As a Software Development Life Cycle Model?
Software Development

Agile or V-Shaped As a Software Development Life Cycle Model?

Agile and V-Shaped are two of the most popular life cycle models. Today we'll take a look at their relative strengths and which kind of problems they solve.

Guillermo Carreras

By Guillermo Carreras

As Director of Delivery, Guillermo Carreras implements BairesDev's campaigns while focusing on Agile development and digital transformation solutions.

10 min read

Featured image

One of the most common questions I get when talking about a new project with a client is “When will it be done?” Taken in the most literal sense, the answer would be “never”. Software development is a process that never ends.

Fortunately, most of the time this question can be translated to “When can we have a working version of the product?”. The difference here is subtle but important. Going to production and having a working product is very different from “finishing the product once and for all”.

Software projects are never truly “done.” Yes, you could theoretically go to production, close your IDE and never write another line of code in your life. But, even then, the process isn’t over. As time goes on and technology changes around our software, it starts to age. 

There are myriads of reasons why a perfectly serviceable product can break down: changes in hardware architecture, modifications to APIs, and new disruptive technologies. Even something as simple as an undiscovered bug in the programming language can be a catalyst for change.

This is one of those cases where deterministic machine models fail to grasp the complexities of the market. You can’t just algorithmically build software that will last forever. In truth, software projects are similar to organic processes. Like living organisms, they grow, change and survive by adapting to their environment. And that’s precisely the reason why we talk about the Software Development Life Cycle.

Today we’ll take a quick look at two of the most famous SDLC models, agile and V-shaped. We’ll give an overview of the process, compare their strengths and weaknesses, and recommend what types of projects are the best fit for each style. 

What is Software Development Life Cycle

Software Development Life Cycle (SDLC) is an opinionated division of the stages (or steps) of software development. It serves as a way to understand, manage, measure, and improve the development process. As a business practice is one of the most widely accepted models in the industry. 

It’s a cycle because it’s an iterative process: once you go through all the stages, you go back to the beginning, making changes based on the previous cycle’s feedback. In formal terms, we can describe it as a cybernetic loop.

It’s opinionated because it’s derived from a paradigm. For example, while both Waterfall and Agile talk about SDLC, the implementation is quite different, each playing to their particular strengths.

Beyond being a model, SDLC is a powerful communication tool for both the development team and the client. It’s very easy to explain where a project is at by talking about the stage it’s in. It sets clear goals and helps you maximize efficiency at each stage.

A good SDLC is a must for companies seeking to reduce costs, deliver better software faster, and adapt to market trends and scale. The SDLC helps achieve these goals by identifying inefficiencies and fixing them to run a smoother operation.

What Are the Different Software Development Life Cycle Models

There are dozens of models to choose from, from the structured and traditional waterfall model to the almost lesson faire approach of Agile models like Scrum or Kaban. It would take a lot longer than a single article to go over each and every one of them.

Instead, our time is better spent talking about why they are different. No two projects are alike, no two teams are alike, and when you mix and match both it stands to reason that different teams will have different ways of tackling the problems and goals of each project.

I like to organize SDLC models in a continuum, on one end we have the low-user-engagement heavily structured, and linear approach known as Waterfall, on the other end we have highly involved, loosely structured Agile approaches. 

Today we’ll take a look at two models, each one representing one of the extremes of this continuum.

Examples of Software Development Life Cycle Models

The V-Shaped Model

The V-model is a type of SDLC where the process is executed in a sequential V-shape. It’s commonly referred to as the Verification (Static reviews without running code) and Validation (Dynamic review based on code execution) model. The life cycle is divided into Verification stages (on the left side of the model) and Validations stages (on the right side), both sides meeting on the coding stage down at the bottom. 

Each testing phase has to be done sequentially. As you go down each stage, the distance between verification (on the left side of the model) and validation (on the right side) shrinks as the product takes shape, collapsing into a common node in the final stage called “Coding.” This gives the model a shape that looks like the letter V. 

Validation phases:

  • Requirement analysis: Detailed communication with the customer to understand features and requirements.
  • System design: Designing the system and setting up hardware and communication configurations.
  • Architectural Design: The system is broken down into modules for different functionalities.
  • Module design: Each module is further defined and broken down into sub-modules.

Testing phases:

  • Unit testing: Test plans designed during the module design phase are executed to eliminate bugs at the code or unit level.
  • Integration testing: After completing the unit tests, testers check for integration, i.e., if all the modules fit together and communicate without bugs. This is done in the Architecture design phase.
  • System testing: The complete application is tested with all its functionalities. This is done during the system design phase.
  • User acceptance testing: UAT is performed in a user environment that resembles production. UAT verifies that the product meets the user’s expectations and it’s ready to use.


  • Very easy to manage and track thanks to its hierarchical structure.
  • Problems are detected at an early stage.
  • Disciplined model where stages are completed one at a time.
  • Great for small projects where requirements are clear.
  • Simple and easy to understand and use.
  • Focuses on verification and validation activities early in the life cycle, which helps to prevent bugs down the line. 


  • Rigid nature turns it into a poor match for complex and object-oriented projects.
  • Struggles when requirements aren’t clear or constantly changing.
  • Very difficult to handle concurrent projects or events. 

The Agile Software Model

In stark contrast to the fixed nature of the V-shaped model, Agile embraces the chaos and flexible nature of software development. While there are many different Agile models such as Scrum or Kanban, they share enough similarities to be able to talk of a single SDLC.

Typically the Agile software development life cycle consists of 6 stages:

First up is the Concept phase. The product owner will determine the scope of the project. In the case of having several simultaneous projects, the owner prioritizes the most important one. During this stage, key requirements are established in tandem with the client, and documentation outlining the project is prepared for the team. 

Due to the iterative nature of Agile, it’s best to start with few requirements and scale up as the project is built.

Then comes the Inception with an outline in hand the product owner builds the development team by checking with their colleagues and/or hiring new developers if required. The idea here is to align the team’s abilities with the requirement for the current project. 

At this stage, the team will build a mockup of the interface and a first approach to the architecture. In some cases, the product owner will show this to the client to gather feedback and make changes as they see fit. 

Then comes the Iteration. It’s the longest phase, as the bulk of the work happens here. At this stage, UX designer notes, customer feedback, and product requirements are all combined to turn the design into code. 

The process is inherently iterative, going from short work bursts (like sprints) to testing and feedback, building the software while also fixing bugs on each iteration. This is the cornerstone of Agile. 

The next stage is Release. After QA performs the necessary tests, the team goes to production. Bugs are to be expected during launch, so the team is ready to address them as swiftly as possible. User training takes place during this phase.

The final phase is Maintenance. With the software fully deployed, the team focuses on providing ongoing support to keep the system running smoothly and squish any unexpected bugs. Additional training is provided as requested. Over time, new iterations can take place to update the product.

Finally, there is Retirement, a stage that only happens when the software is going to be phased out. In this phase the team prepares to bring down the system, easing the transition to the new system when necessary.


  •  Dynamic development that adapts to changing circumstances
  •  Problems are detected quickly and processed during development. 
  •  Great for big project with many moving parts
  •  Users and clients are pivotal to the process.
  •  New features can be added at any stage


  • Requires discipline and expertise, since the lack of direction can quickly devolve into feature creep.
  • Extremely susceptible to miscommunication.
  • Not a great fit for business with extremely tight deadlines or strict regulations that require timetables.

And the winner is… 

To no one’s surprise, both models are perfectly viable approaches to software development. The choice then boils down to the nature of the project as well as the expertise of the development team. It’s better to have a team who knows and understands the V-shaped model working it than forcing them to work with Agile, regardless of the size of the project

Guillermo Carreras

By Guillermo Carreras

Guillermo Carreras focuses on digital transformation solutions and Agile development work as well as the management of BairesDev's successful campaigns. As Director of Delivery, he works with PMO, Sales, and Tech teams to provide end-to-end company alignment.

Stay up to dateBusiness, technology, and innovation insights.Written by experts. Delivered weekly.

Related articles

Contact BairesDev
By continuing to use this site, you agree to our cookie policy.