Agile or V Cycle?

I often read heated discussions about 2 of the main approaches regarding project development: should it be Agile or traditional? Short answer: it depends and most probably both.


When we talk about a project, we often confuse it with the product that should come out of it. True, without a product there would be no project but how many ways do we have to reach the goal? The simple answer is many. A project is a process that produces an outcome, and project management is the process of managing this process. If we take it from a methodology standpoint, this process becomes a product. This level of analysis is usually called a Project Management Office but let's leave it for another post.

Before we dive into more details, let's take 2 examples and see which approach would be a best fit. First, the car maker Dacia wants to make a copy of the Renault 12. Second, my CEO has a brilliant idea for a revolutionary product, we need it in 6 months, we know that it's blue and has horns but we haven't figured out yet whether it has wheels. Let's take a structured approach to decide which methodology fits best.

We all understand what a product specification is, or at least what it should be. What we often fail to examine is the specification of the project, which covers a number of metrics - for instance:
  • What is the nature of the project?
  • What is the maturity level of the product requirements?
  • Does it imply a research phase?
  • What is the time pressure?
  • Does the team have good communication channels?
The answer to these questions will give us some clues on how to manage the project.


These 2 approaches target different goals and comparisons are not necessarily simple. The V Model is about developing the "right product" while Agile is about getting the "best product within the budget". The definitions behind these terms have been - and still are - the cause of long arguments between both communities. By "right product", the traditional approach means extensively defined: the project is initiated with a quantifiable goal in mind and a specific solution. The project is then planned with the big picture in mind, looking for possible optimizations in the execution. With the right breakout structure, it is possible to define the actual progress and detect early any drift in the execution. The risk is to end up with a product that does not respond correctly to the market need - since this will be detected only at the end. On the other hand, Agile favors the "best product within the budget", meaning that the product is defined in iterations using an exploratory process and periodic meetings, at the expense of possible reworks and a permanent, costly management.

The V Model first appeared at Hughes Aircraft around 1982 (Wikipedia) as an attempt to control the development processes. At the time, it attempted to solve a chaotic approach often found in development teams. In the 1990's the rise of a faster software industry created a new paradigm, leading to the creation of the Agile Manifesto. You can find a very informative article here. These 2 models are complementary and should be used in the right context.

Nature of the Project

Let's get back to our examples. If Dacia wants to copy a Renault vehicle, the best approach is to buy the design and set up the production line. There is no incentive in taking an Agile approach since everything is defined. On the other hand, the CEO's revolutionary idea lacks some very basic requirements so the first stages of development are likely to be a waste. We may even find out that the market was looking for a red firemen's truck - just one horn, red instead of blue but the product finally delivered met the expectations. A V Cycle would have been a disaster here.

As always life is not black and white. Let's consider an 8-storey building: Agile or V Cycle? Talking about the infrastructure, there isn't much to discuss: making changes during the execution phase is likely to cause either excessive cost or cause stability risks. Does it mean that Agile is completely out of the picture? Not so fast: if a buyer wants to get 2 flats and join the 2 living rooms to make a bigger one, it is just a matter of omitting a non-structural wall. The same applies to the decoration, paint and other minor changes. All of these can be handed in an Agile way.

In most domains of engineering, most parts of the projects require significant investments and careful planning. These parts are not candidate for Agile. Software engineering is somewhat different and supports to some extent major rewrites in the middle of the project - it is necessarily not good practice but it is not unthinkable either. This is why Agile became popular in this context.

Now, let's assume that we want to design a new medical drug. Do we have an extensive specification? No and we even have to start with a research phase. Research is, by essence, Agile: the team must experiment and, depending on the outcome, decide which way to go. Can you imagine Viagra developed with a traditional approach?

The People

Beyond all technical aspects, the project will ultimately be run by people and you must ensure that they have the right profile. In the case of V Cycle, the team members must have a consistent approach and be open to long, complex sprints. Communication always helps but a lack thereof is not a show-stopper.

On the other hand, Agile groups must have excellent communication skills since it will represent a significant part of the projects: daily stand-up meetings, sprints kick-off, design review, etc. Agile teams should also be open to changes and redefinitions on the way, and manage this form of stress.


Clearly, these 2 methodologies have their place and design teams are bound to use them at some point. The real question is how to define which parts of the project will be run in one or the other form. This is what the project manager will have to deal with. Nevertheless, the market dynamics also requires an ever higher level of flexibility from  the development teams, which explains the recent popularity of Agile.