Waterfall or Agile? Predictive vs. adaptive SDLC explained

Evolution of SDLC methodologies

When software development became mainstream in the early 1980s, it suffered a kind of crisis; the discipline was visibly immature. Most development shops ran with a cowboy development mentality, with no holistic method to generate software for the business.

Many voices called for a more structured approach to software development. Through the 1990s, software teams emphasized how to create a sustainable, disciplined and repeatable development process. From this movement, we gained a sequential set of phases to design, construct and deploy software to meet a business need. Often referred to as predictive SDLC methodologies, these sequential processes treated software development as a strategic engineering exercise.

While there are benefits of a disciplined predictive SDLC methodology, it also has drawbacks. Predictive strategic approaches couldn't maintain appropriate development velocities as organizations demanded more rapid deployments. The processes that made predictive approaches repeatable also slowed down development. Software development must be both fast and exact to meet stakeholders' expectations.

Software development required more tactical approaches -- called adaptive SDLC methodologies -- to the SDLC. These approaches stress:

• development discipline;
• people instead of process;
• flexibility; and
• development in the small, a concept for incremental software development.

When looking at the predictive vs. adaptive SDLC debate, it's clear that both approaches have strengths and weaknesses. Development teams need to know the principles and deliverables involved, and their purpose. Developers must understand and respect the guiding principles of each process but be able to change those principles to meet the unique needs of the IT organization. Make clear to the development team the expectations and purpose of every aspect of the SDLC approach. Also, communicate how the methodology should adapt to meet business needs.

Predictive SDLC methodology: Waterfall

Waterfall is the classic predictive SDLC methodology and considered the easiest to follow.

The Waterfall process is a set of sequential phases:

1. Requirements definition
2. Design
3. Development, which includes coding and unit testing
4. Deployment to the main code repository and to the test server
5. Functional, regression and system testing
6. Deployment to production
7. Maintenance and customer support

In Waterfall, the software team completes each phase before they begin the next one. Software development methodologies derived from the Waterfall model usually have a clear set of gates -- or check points -- to decide when a phase ends and the next one begins.

A development team can choose from several tool sets to manage a Waterfall development process. With the support from tooling, developers can deliver software releases in a predictable manner and with a high-quality level. Tools can track resource time, how long development and testing take and status with the release.

For whom predictive methodologies are a good fit. Waterfall and similar predictive software development methodologies are apt for organizations in these scenarios:

• Staff has a high percentage of junior developers.
• The developers have a mix of different levels of experience.
• Software is structured on unchanging requirements, where customer expectations are known and documented accurately.
• A business is subject to extensive regulatory requirements, including international or foreign regulations.

The predictive approach's strength is its focus on structure and steady development speed with easily trackable project progress. One weakness, however, is the inflexible nature of the development lifecycle, which progresses strictly one phase at a time. When each group -- from development, to test and operations -- has to wait for incremental project completion, the project tends to fall behind schedule.

In this inflexible lifecycle, customer needs can go unmet. As a result, teams should consider a software product for a diverse and evolving customer set. By the time the Waterfall project gets into the testing phase, many of the actual design choices and requirements have changed. Developers must update requirements and notify other teams downstream of such changes. Requirement changes create rework -- which in turn, slows down the release schedule and leads to more costs from added design, deployment and testing work.

Adaptive SDLC methodology: Agile

Agile is the classic example of an adaptive methodology. Agile methodologies follow the Agile Manifesto, a set of core principles that support iterative development and quicker delivery of the software product often in stages. The Agile Manifesto values:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation; and
• responding to change over following a plan.

The Agile Manifesto also includes 12 principles:

• customer satisfaction by rapid delivery of useful software;
• working software is delivered frequently;
• working software is the principal measure of progress;
• changes, even late changes, in requirements are welcome;
• close, daily cooperation between development team members and stakeholders;
• immediate communication is the best way to convey information;
• projects are built around motivated individuals who are trusted;
• continuous attention to technical excellence and good design;
• development processes are sustainable for all involved;
• simplicity;
• self-organizing teams; and
• regular adaptation to changing circumstances.

Agile has a broad definition and encompasses frameworks such as Extreme Programming and unique adaptations centered around continuous deployment. What's common to all adaptive methodologies is an iterative, tactical approach to software development. Teams focus on their abilities to deliver functional software in small packages.

For whom adaptive methodologies are a good fit. Adaptive methodologies are an apt fit for organizations in these scenarios:

• The software does not adhere to any particular regulatory rules.

• The team includes a high percentage of senior developers.
• There are a small number of developers working on the project.
• The dynamic business model sees requirements and customer expectations change frequently.
• The organization can manage constant change effectively.

However, Agile does have weaknesses, namely its disorganization and lack of communication. Last-minute changes can become habitual and cause significant defects in the code. Additionally, teams that don't communicate changes in design or functionality well can suffer delays, surprises and rework.

If a development team decides to use Agile or a similar adaptive SDLC methodology, anticipate a learning curve; developers will need time to adjust to working with others more extensively and communicating more frequently.

Expect to make changes to any SDLC process to match the needs of the business and the software development team. If a development team adopts Agile, it should follow the main principles but also alter them to reflect business-side needs. Developers, for instance, may need to meet regulatory requirements that require more robust documentation and must adjust their practices accordingly.

Decision time: Predictive vs. adaptive SDLC

Before jumping on the bandwagon of an SDLC methodology, a development team should determine what problems exist in its current approach. It must figure out why what its developers are currently doing is failing.

Changes to how developers, testers, operations and stakeholders create and maintain software should be conservative and not too frequent. A new process needs time to come together before more changes occur. Otherwise, it's pure chaos and team members will revert to what they've done in the past.

Predictive vs. adaptive SDLC comparisons illustrate that both methodologies serve a purpose. If pure Agile or Waterfall isn't the right answer, a dev team should mix and match to find what works for it, its customers and the business. For example, add the concise documentation step that's part of the predictive model to an Agile development and test approach. Add an iteration for documentation that runs simultaneously with testing or development. The development team may not technically release documentation with the software, but it can make iterative releases to meet internal needs.

It's not uncommon to blend Agile and Waterfall. Few applications go through a release every few weeks -- customers cannot test or accept releases that often. Here's another example that combines adaptive and predictive approaches: Development teams can adopt Agile but release internally, building a full software release iteratively. Then, the team performs thorough regression testing before the release deploys to the customer. This approach can help expose defects better than short iterations do.

A development team should try different approaches to find out what works best for its developers. The team can see how the first release goes with a predictive Waterfall progression; perhaps developers watch to see if the requirements or design phase takes too long. Waterfall followers focus on getting the exact customer requirements right -- unlike Agile, changes along the way are discouraged. If the software developers cannot logically meet these requirements, the Waterfall project has to move backward to rework requirements. In such a predictive, phased approach, delays can cut into the time available for later stages. In this example, the rework might mean there isn't enough time to test properly before the release date.

This case illustrates how knowledge of both adaptive and predictive SDLC methodologies can pay off. To combat the slowdown and rework cycle, teams can use an adaptive technique -- such as Kanban or Scrum -- to coordinate requirements, design and coding and then hand off to testing. When some phases work simultaneously, the team finds out about changes needed for customer requirements faster, long before the design is set and coding underway. This synthesis of adaptive and predictive techniques preserves the testing schedule.

Try other adaptive scheduling to see if different approaches pay off. For example, start testing at the same time as coding. Granted, you'll likely have to repeat test execution, but you'll find defects as soon as possible. This method can lead to faster releases.

Customizing the SDLC isn't a one-time exercise. Alter processes over time as needed so that development, test, release and support best fit the needs of the team and the customer.

Editor's note: This article was originally published in 2010 by David W. Johnson. It was updated in 2020 to provide more information on Agile, Waterfall and how to use each methodology, including a blend of the two, by Amy Reichert.