One of the reasons why organizations transition to agile is to become more able of handling changes. The needs of customers often change along the way, which requires development teams to be able to adapt the product requirements. Agile helps teams to deliver products that satisfy the needs of their customers; products which do not contain unneeded (and unused) features. Lean software development uses the term waste: everything not adding value to the customer is considered to be waste. How can a transition from waterfall to agile software development help organizations to reduce waste?
Ron Lichty wrote a blog post about the most convincing reason to change from waterfall to agile. The reason, as Ron states, has to do with waste:
But what truly clinched it for me - what converted me from enthusiastic about agile to downright disenchanted with waterfall - is waste. Waste of resources, waste of development time, waste of effort.
He describes how he questions developers and development managers on what percentage of a 400-page requirement specification that they haven been given has actually been delivered. The answers he gets are:
(…) the responses seldom exceed 45 percent - are most typically 15 to 25 percent - and range as low as 10 percent of spec requirements delivered.
Ron sees a major difference between agile and waterfall on how the decisions are made on what will be delivered, which impacts the value that is delivered:
One of the things I like about Agile is that the top of the backlog is ordered every sprint by product owners collaborating with development leaders to ensure that the team is always working on the highest value stuff.
The answer in a waterfall scenario, on the other hand, is almost never value. The answers I get to my question include, "the easiest stuff to code," "what was most interesting to us" (what was most shiny!), "what stood out in our minds from reading the requirements," or "what was the most fun." Prioritization in 400-page waterfall requirements is almost universally done by developers, not product owners.
On their website the lean mindset Mary and Tom Poppendieck describe the principles of lean software development. One of the principles is “eliminate waste”:
The three biggest wastes in product development are:
Building the Wrong Thing
"There is nothing so useless as doing efficiently that which should not be done at all." – Peter DruckerBuilding the Thing Wrong
If it seems like there is not enough time to build it right, then there certainly is not enough time NOT to build it right.A Batch and Queue Mentality
Work in progress hides defects, gets obsolete, causes task switching, and delays realization of value.
Mike Cudemo wrote the blog post agile vs. waterfall – what is the big deal? He starts by explaining the different way waterfall and agile handle requirements:
The waterfall process attempts to “freeze the requirements” after the blueprints are designed. As you can imagine, this is not reality. The later you catch a requirements problem (…), the more expensive it is to fix. In some cases, it is impossible to fix. (…) The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time. It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements.
He give his view on how iterations in agile software development offer possibilities for steering the outcomes:
The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases. Essentially, the Agile Method is a series of smaller contained waterfalls. End users and business stakeholders get to see and experience the system as it unfolds. Course corrections become more apparent and easier to navigate.
Waterfall projects are wasting the IT budget, as Mike concludes:
Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments. CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.
In the article agile is cheaper, right?, Kenny Grant describes how an agile approach can help teams to identify waste, and to deal with it. Agile software development in itself is not cheaper then waterfall to develop software, as Kenny explains. What makes agile cheaper is the way that it deals with scope changes and project adjustments:
So comparing waterfall with agile is like comparing apples with oranges. This is because following agile principles and processes would, in my opinion, nearly always generate a different product than if the same business need was addressed using a waterfall-type methodology. (…) there is nearly always some parts of the scope that can be considered waste or their value is not worth the cost of delivering. Agile’s relentless focus on business value and just-enough-work identifies this waste—or poor return of investment (ROI) requirements—and gives the team the opportunity to change it or leave it out all together.
Taking into account that business needs and requirements will change during a project, Kenny rephrased the question if "Agile is Cheaper?”:
“For a specific business need, will following agile principles and processes enable us to develop a product that meets those needs (no more, no less) more cheaply than if following a waterfall type methodology?” In this case the answer is “Yes, absolutely!”