Agile vs. Waterfall – It’s Debate Season Again
My view is we can declare the debate between Agile vs. Waterfall over, but before we do, let me attempt to make the case. Late last year, Gartner released a report highlighting the need for CIOs to embrace agile development along with a recommendation that IT leaders and executives adopt this methodology as quickly as possible.[i] With many CIOs and IT leadership under intense pressure to support fast-evolving strategic transformations, companies are finding traditional project and software development methodologies unsuitable, according to Gartner. Enterprises are turning to Agile development to speed up projects and illustrate their value and companies that delay the decision are paying a big price in the market.
Technology leaders instinctively know that companies in the modern technology-driven era that are unable to drive a process that is built for rapid evolution will struggle to compete. So the why is well established but the how is still a little muddy for some. The same driver that has been there for the last 20 years is still at play. The difference is the processes and tools to do agile at scale are now becoming main stream.
Let’s look at the two concepts one last time and discuss both approaches starting with the waterfall method.
Waterfall - The “Traditional” Methodology
Often called the traditional or classic approach – this method is linear and sequential. Waterfall is one in which each phase of a product’s life cycle takes place as part of a flow or a sequence of events. One step leads to another, hence the name Waterfall. Progress on one step needs to be completed before the next step or phase can begin. Once the concept is created it moves to design, then implementation and then further down the line until the product development cycle is completed.
In this method, all the planning is completed up front. All the requirements gathering, design work and more has to be completed before any development and coding begins. Once the project moves on from one stage to the other, there is no turning back.
Companies that followed the Waterfall methodology achieved these perceived benefits:
- Requires less coordination due to a stage-gated sequential processes
- Phase steps are clear since they are modeled and processed one at a time
- Cost of the project can be estimated after the requirements have been defined
- Better focus on documentation of designs and requirements
- Design phase is more methodical and structured before any software is written
Agile – A “Movement”, not just a Methodology
Agile evolved out of a variety of software philosophies to demonstrate alternatives to Waterfall. In early 2001, a group of software development practitioners discussed their shared ideas and various approaches to software development. This culminated in the introduction of Manifesto for Agile Software Development and the corresponding twelve principles. [ii]
Agile software development methodology is an approach that follows an incremental, iterative path. Unlike the Waterfall methodology, where extensive planning and design occurs up front, Agile methodology allows for changing requirements over time. A cross-functional team made up of designers, developers, testers and more focus on development of the product over a fixed period of time. This defined period of time is established by the team and usually lasts 2 – 4 weeks.
At the end of each iteration, the goal is to present a product to the business owners. The software is delivered incrementally over time instead of delivering one final product at the end. Each phase is a key part of a continuous process vs. a fixed step by step approach. With the Agile methodology, the focus is on consistent communication and short feedback loops. So, if a team is heading in the wrong direction, the feedback they receive will let them know right away vs. waiting until a lengthy development cycle is completed.
Agile provides the following perceived benefits:
- Faster Feedback Cycles
- Identifies problems early
- Higher potential for customer satisfaction
- Time to market is dramatically improved
- Better visibility / accountability
- Dedicated teams drive better productivity over time
- Flexible Prioritization focused on value delivery
Which approach is better?
This question seems to never go away but the software world is finally turning the corner on the debate. Two truisms: Software Eating the World = TRUE and Agile is Eating Software = TRUE. There are cases for a slower and more stage gated process with some projects but for the vast majority agile is the future.
Blending the two worlds is important during the long transformation journey but the debate on the merits is clear. With the continuing need for enterprises to retain a competitive advantage in their market place, Agile is an established methodology allowing companies to drive better results (plain and simple).
Agile allows for increased flexibility, which enables teams to better react and meet their customer’s needs. Agile creates the ability for companies to capture maximum value for the dollar and avoid unnecessary overhead / budgetary spending.
In the end, it comes down to enterprise business agility. What you call your software process / method is not the point. The point is your process had better be flexible enough to drive innovation and keep up with your market / your competitors or you may end up the Kodak, Circuit City or Blockbuster of the software world.
What’s next? Check back for part 2 of our series “We’ve decided to go agile, now what? Key steps to readiness”
[i] Gartner clients report "Ten Things the CIO Needs to Know About Agile Development."
[ii] Principles behind the Agile Manifesto http://www.agilemanifesto.org/principles.html