Waterfall or Agile? Which one should I choose for my project?

Following the results of the recent Version One survey regarding Agile importation in the world’s companies, we would like to return to a question that many ask themselves even right now. What’s all this fuss around Agile about? Is Waterfall a wrong approach? How do you determine which methodology to choose or stay with? .

Let’s consider the questions one by one.

Is Waterfall a wrong methodology to use in approaching a project? No. It is not wrong by the fundamentals. Perhaps there is something from where it takes the origins, but it is not an IT-specific methodology. Rather, it’s an adaptation of a particular approach to the process of product delivery taken from other industries. As with a traditional product, gathering requirements and designing takes place before the manufacturing, here, coding.

The main challenge that could be seen from the beginning is the singularity and sequentiality and risks it bears. –Specifically, it takes a long time to deliver a ready-made product to the client, and the potential for failure exists. It is not uncommon for customers to know 100 percent what exactly they need, to every dot, and it can turn out that they will receive a product that even at its best does not match given requirements or scope. It can just create a project that fails. A long delivery time occurs because all project phases come sequentially one after another. Each one takes time to proceed and deliver a result. Conception. Analysis. Design. Planning. Coding. Testing. Risks come with the timing. One of three problems can occur on our path to success:

• A) Poor visibility of the outcome. Usually, as soon as a project hits the coding part, someone realizes that the requirements or expected results are not clearly defined, and there’s a problem in how they are stated. Maybe they are too fluffy. Maybe there are contradicting requirements. Sometimes, it is just that there is no way to see flaws in the design until the project enters the coding phase or later. The requirements have to be short and at least fit within the budgeting year. Based on research and postimplementation surveys, the main reason for the failure of IT projects is wrongly specified requirements and trying to respond to them “on the way” while building the product. This problem has not changed in last forty years!
• B) The risk of low quality. When a project’s budget and dedicated time are running dry, it is usually in the testing phase. Hence, to deliver on time, tests have to be cut off, and quality suffers.
• C) No maneuverability. In other words, a problem arises when trying to adjust to change, which can come about because the client has just realized what he really needs or you encounter a complicated problem, with a lack of resources. Both often appear in the last phases of the project, where delivering the remaining 20 percent of the solution uses about 80 percent of resources and time. This situation often results because by the end of development all new features, changes, or updates come with much higher costs and require more time to rebuild or modify the source code when it is already well integrated and advanced.

That being said, some projects and systems just cannot be run using Agile. These are Safety Critical Systems, which operate in such areas as banking, automotive, aviation, and healthcare. Every part of the system must be able to be specified and audited. For such projects, code that is not finished or of low quality could result in potential serious damage, harm, or loss. Those companies cannot afford such risks, even if the product will be developed and delivered more slowly.

Waterfall also has its advantages. It is well structured and described, so most of the time clients know (or should know) exactly what they will receive (at least by their requirements). Each step is well documented and described by analytics, designers, and developers. Thanks to detailed analysis and documentation, the project is safe from employee turnover. Moreover, many clients find its detailed record of activities and documentation reassuring. When client and contractor focus on the outcome and speed is not a primary factor, Waterfall may be a better approach. The singularity of the development process is also much simpler to present and understood by the business (nondeveloper) roles in the organization.

Agility - what started in 2001.

Agile evolved out of many various lightweight software philosophies that took root in the ’90s as a counterpoint to a heavyweight waterfall. The Manifesto for Agile software development, written in 2001, shows the emphasis on value delivered to users, communication, and feedback to progressively create a product.

How is Agile different? It takes sequences as a core implementing incremental, iterative approach to product development. Each step consists of all product phases—Analyze. Design. Code. Test. Instead of planning and designing all the product up front, it concentrates on creating and producing minimum viable products delivered in short time periods. Every iteration brings progressive improvements to the products or new functionalities. The project is executed by cross-functional teams that are primarily self-organising. Apart from designers, analysts, planners, developers, they include “project manager” roles and supportive functions as well as a business representative, who is the product owner. Each MVP will be demonstrated to stakeholders, and their feedback is incorporated into the next or future iterations.

Can you already see how the Agile approach is “better”? Advantages of Agile.

First, the quality of the outcome improves because testing starts simultaneously, not in the last phase of the project. Second, visibility of the final outcome improves because you are halfway through only when you have built half of the required features. Third, thanks to tightening of the feedback loop, risk is reduced, and your clients will be happy because they can make changes to the project without paying excessive additional costs. It sums up with the first point allowing productivity of the Agile teams to improve. By giving flexibility to developers, as people coding their way through the user stories, they can often solve problems easier and faster. It also offers a faster time to market, and if change is needed, a shorter time to adjust to the situation applies.

These are just general points. In the VersionOne’s report, there is one particularly interesting question: “Why did you choose Agile in the first place.” –The answers: “Accelerate product delivery” as said by 69% of respondents; “Enhance ability to manage changing priorities”—69% of respondents; “Increase productivity”—over half of respondents (53%); in fourth place in the rank ad ex aequo, “Improve project visibility” and “Enhance software quality” selected by 42% of people who took part in the survey. As for the sixth point, “Reduce project risk,” as said by 37% of respondents.

Agile is not a silver bullet. It is just an approach, a tool. If used by inappropriate hands, say, an inexperienced project manager, it can slip out of budget control and turn to pure code sprints. If what the client expects is not understood correctly, a fiasco may result.

Disadvantages of Agile

Regarding disadvantages, as we mentioned earlier, it requires customer involvement. Some clients may not be interested in participation simply because they don’t have time or are not interested. As engagement is great for the project overall, it might also bring some potential problems. It often leads to additional features requests, which adds to the cost of implementation and delivery time.

From a system engineering point of view, as experts point out, the iterative development may lead to frequent code refactoring in case the full scope of the system is not matching its initial design model and architecture. If skipped, the product may be of lower quality. This problem is more visible in the highly integrated systems or greater implementations. Again, this adds to overall costs. Also, limited time sprints and changes in features priorities can lead to a delay in delivery or additional sprints beyond what is planned

Agile brings challenges to overcome.

In a traditional approach, required system functionalities can be divided into pieces, and each dev team, even the distributed one, can start working on their part of the system, which brings us to the central challenge. Developing a product piece by piece, with the possibility to change or refactor the code on the way, Agile methodologies require full team dedication and coordination. However, it is just a tool you have to use—both for communication, such as with Skype, messengers, and Slack, or through collaboration on tasks and documents.

To sum up: Faster time to market, shorter reaction span for changing situations, e.g., the market and changing business goals, but a clearer outcome and a higher quality of the end product is the result.

Agile is also just a step toward a more lean and flexible approach to project management. It is not something that you install from the box and it just works. From a wide range of methodologies and methods, you pick the one that will work best for you and the project your organization is currently running. Then, it is a process. You excel only when working on it and scaling your operations. Moreover, it requires not only changes in your approach to a project but also often changes in organizational culture, team structure, and additional support of external or internal Agile coaches (experienced practitioners of Agile methodologies), support and sponsorship from executives, and also implementing the right common tools among the teams.

Regarding methodologies, according to the 11th State of Agile, the most popular one (68% of organization) is still Scrum (58%), and Scrum connected with Extreme Programming (XP) (10%). Later down the charts we see Scrumban (8%), Kanban (5%), and hybrid models (8%).

There is also one methodology that leads to more flexible and fruitful team collaboration - DevOps. VersionOne’s report indicates that “71% of respondents stated that they currently have a DevOps initiative (50%) in their organization or are planning one in the next 12 months (21%).”

For more interesting conclusions, I invite you see the summary made by Leanintuit team, which covered all nine years that the survey was conducted.

For those of you who are too busy too read the full story -- TL;DR

Neither Agile nor Waterfall is a magic recipe that will take the client’s expectations and deliver a box with the product and solve all problems on the way. The right approach depends on the project, clear definitions of requirements, and attention paid to the project throughout its journey.

Share your opinion on choosing the right approach. What are your thoughts on project management methodologies? Which one is successful in your organization?