Developed for industry and then applied to IT in the 1980s, the

traditional “V” project management method, also known as

Waterfall, has long established itself in development logic. The

classic method establishes the principle of dividing the project

into six or nine successive stages which will be validated before

moving on to the next. Hence the eponymous "V" in the

appellation. In addition, the shape of the letter also recalls the

diagram when describing the process. The different phases are

sequenced as follows: needs analysis, drafting and validation of

functional specifications, architectural and functional design

stages, realization, unit tests, integration tests, validation test

then functional acceptance. As for Waterfall, by analogy with

this series of tasks performed in sequence, one has to imagine

a waterfall rushing down a slope and which, moreover, can no

longer go back upstream.

No going back

As soon as one stage is completed, development moves on to

the next, with no possible going back. One of the advantages

of the method is to facilitate management control. It makes it

possible to set a schedule and to consider steps to support the

development process. Of course, the phases follow each other

in strict order, without any overlap or iterative steps. Also,

V-cycle development does not allow for revisions or even

reflection. Therefore, it is very difficult to step back to modify a

previously poorly designed element. Moreover, each phase

being devoted to specific tasks, it is dependent on the results

of the previous phase.

The advantages of V-style management lie in its ease of

implementation and explain its adoption by industry and later

in the design and development of computer software. This

systematic planning allows development without any customer

involvement until the project is delivered, its expectations

integrated in it from the start of the project. With an upstream

global forecast, the Waterfall method also provides a perfect

outlook in terms of budget, achieved performance at each

stage and therefore delivery.

Risks of discontinuity

But the lack of flexibility can also be troublesome. In effect, this

very structured progression framework does not allow the

integration of unforeseen events such as technological

developments, the emergence of new competitors, the creation

of new markets, the evolution of production and distribution

standards, etc. Of course, taking into account these possible

occurrences involves calling into question the work of the

teams, with the risk of generating delays and additional costs.

Finally, the end result must be perfect to satisfy the customer

since in this model, they will only discover what it is upon

delivery. So be careful with the risks of discontinuity between

the initial expectations and the final product.

The Customer is at the center

As for alternatives, there are other substitution solutions.

To name a few: Agile Scrum, the adaptive method, the critical

path method, the PERT method, PRINCE2, Kanban.

Due to the flexibility it allows in terms of product design, the

agile is the one method favored by startups in particular.

At the origin of "agile" practices, there is a finding about

counter-productivity. It was realized that it was unnecessary

to plan a project in detail and that it was essential to improve

communication between the different actors of the project.

 

In an agile process, the customer's request is at the heart of

the action. The teams are therefore more responsive in a

development framework where changes are easier to make

along the way to improve the product. The project is often split

into several mini-projects, each requiring client validation to

move on to the next. Agile practices are based on adaptability,

dialogue and cooperation with the customer. The agile method

also relies more on interactions between team members rather

than documentation. The time factor is also to be taken into

account. Here, the objectives are more of the short term kind.

Deadlines are shorter and the rest of the project will be planned

according to the previous achievement. At the end of each step,

the delivery is tested. If the result is conclusive, one goes to the

next functionality, otherwise, corrections are made.

With this more flexible approach, it is much easier to adapt to

changes and unforeseen issues. These days, the most used

agile method is the Scrum method.

The differences between V-cycle and Agile management

 

 - Project Life-cycle: sequential in V-shape vs iterative in agile

mode. 

- Delivery: a final product, all features are realized in a V-cycle

corresponding to the designed end-product. Whereas in agile-style management, needs are prioritized without waiting for

the complete development of the feature set. Quality controls

are more frequent and avoid the tunnel effect of a V-cycle.

- Customer requests: In a V-cycle, revisiting validated

specifications is a complex matter and a generator of cost as it

is considered to be an evolution of the initial need. In agile

management, it is possible to all feature from one iteration to

the next in a flexible manner. 

- Planning: Detailed in a V-cycle, it allows a good outlook of

the development process, therefore of the budget. Upstream

this preparedness serves to limit modifications once

underway. Inversely, the agile mode permits the onboarding

of new customer requests.

- Documentation: It is the essential basis of a V-cycle project

while it is reduced to a minimum within an agile project.

For which environments?

The two methods respond to the requirements of quite

different contexts.

For the simplest projects, defined with precision and subject to

detailed planning upstream of their execution can be managed

in a V-cycle. This method is perfect to frame a project whose

contours are well delimited.

On a project of more complex proportions, it will be more

coherent to undertake it in an agile mode. In an unstable,

complex and evolving environment, it’s always more

appropriate to have the project keep some margin of

upgradeability. So more so, if the company objectives may

change, external constraints are, likewise, in flux: environmental

givens, competition, regulations, availability of new tools,

marketplace status, and let’s not forget pandemics… Agile

pratiques therefore remain an excellent ace for managing risk

when visibility is reduced. In summary, rather than oppose each

other, one can consider combining the two approaches and

win across the board.

Sources :  techtarget.fr, nutcache.com, planzone.fr, bpce.com, blog.lesjeudis.com, wimi-teamwork.com 

Share this article: