Striking the Balance: Waterfall and Agile - Part 1, posted on

September 13, 2013 by Amol Patki

Today, companies have a plethora of choices such as SCRUM, Extreme Programming (XP), Behavior
Driven Development (BDD), Feature Driven Development (FDD), Lean and Kanban software
development methods under the umbrella of agile along with exiting waterfall method for project
implementation. Companies can select the best combination of suitable methodologies to maximize
business value for the customer.
In this blog series, we will discuss various methodology selection aspects across dimensions such as
business/ application, location and teams, tools and also explore best-practices in both methodologies to
balance agility with discipline and control.
This blog we will be discussing about methodology selection pointers around business and application
related dimension.
It is important that, methodology goals are aligned with project goals. Projects are more suitable for agile
development when the primary project goals are rapid value delivery and responsiveness to change.
Waterfall will the right approach for projects that demand higher predictability, stability & assurance.
Projects that cover significant enhancements, entirely new development or initial prototyping of a new
concept in turbulent, dynamically changing environments where requirements are emergent; agile
adoption is more suitable as it reduces risk significantly. Waterfall is more useful in projects where;
stakeholders desire to have rigorous manual and exploratory testing, there is need to integrate several
independently evolved applications, improperly modularized large existing system is replacing
incrementally.
Agile initially started with small to medium teams of people working on relatively small applications due to
tight coordination and shared tacit knowledge constraints. However, recently, many large scale programs
have documented successful delivery of agile transformation by use of scaling options available like
Disciplined Agile Delivery (DAD), Scrum of Scrums (SOSs), Lean Kanban, Scaled Agile Framework and
SAFe.
For very large projects where plans, documentation and processes enable better communication and
coordination; when the requirements can be determined in advance and remain relatively stable across
large and dispersed groups; waterfall approach can be effective.
Agile can be used in projects with greater dependencies with mitigation through following certain practices
but with reduced benefits that agile has to offer. Waterfall manages multiple dependencies and constraints
as well as systems complexity through upfront detailed planning and coordination.
A successful project needs to fulfill the pre-requisites of customer relationship, i.e., Collaborative,
Representative, Authorized, Committed, and Knowledgeable (CRACK) business partners and
representatives. Agile approach is well suited to projects where crack performers such as product
managers and product owners are identified and dedicated to the project. This allows scope for
immediate response and clear decision making, enhancing communication between the entire team, thus
reducing risk and uncertainty. In waterfall, some form of contract between the developers and customers
is required as the basis for customer relations. They handle foreseeable problems by determining it in
advance and formalize solutions in a documented agreement.
In Agile, undocumented, unclear or poorly defined requirements present very little difficulty and align well
with an agile methodology that proposes just enough documentation whereas in waterfall requirements

have to be documented in detail such that the designers can accurately and proactively predict flaws.
Also, sufficient number of resources has to be allocated for elaborate documentation to keep up with the
goals of predictability, stability and assurance through standardization and process capability.
Agile and waterfall are not exclusive, but there has been considerable polarization associated with both
approaches and much of these differences are rooted more in perception and misconceptions rather than
in reality. In many cases, the manner in which companies apply their judgment and skills in using the
methodology has a higher impact than the methodology itself.
In the next post, I will discuss about how Location and Team dimension impacts methodology selection
considerations for waterfall and agile.
http://www.infosysblogs.com/application-services/2013/12/striking_the_balance_waterfall_Part2.html
References:
1. Balancing Agility and Discipline: A Guide for the Perplexed By Barry Boehm, Richard Turner
2. Agile Project Management with Scrum Ken Schwaber Microsoft Press, 2003