Agile vs. Waterfall

In recent years, many organisations have been changing their ways of working and adopting Agile. This trend has seen the use of Waterfall decline and Agile become the most popular way of delivering software and products.

With this move away from Waterfall, we’re exploring how they differ and if Agile is the golden ticket everyone thinks it is.

Agile in a nutshell

Agile encourages teams to adapt-while-delivering.

The focal point in Agile delivery is not the plan, it’s the customer needs. Teams don’t always know upfront exactly what customers need, and it can change frequently, but one of the strengths of Agile is that teams can test out product ideas with customers, get early feedback and learn throughout. When you break down a large product and release often to customers, valuable features can be added frequently and real-time feedback can be leveraged.

Waterfall in a nutshell

Waterfall encourages teams to deliver-as-initially-designed.

With Waterfall delivery, the project plan is typically the result of considerable effort and upfront analysis and planning. The path to creating the product is then carved in contractual stone, and the team follows that path as diligently as possible - this means the ability to make changes is typically slow and cumbersome.

So how do Agile and Waterfall differ?

While Agile places a lot of emphasis on learning cycles, customer value and adaptiveness, Waterfall leans strongly on following processes and project plans. In my experience, the three most important elements of Agile delivery are:

• Breaking a large idea into smaller pieces, so not everything has to be decided and designed upfront.
• Keeping the customer at the heart of your prioritisation and continuously refining your product according to their needs.
• Taking a cyclical approach, so you can constantly learn and adapt.
  
  

When does Waterfall work?

The occasions when teams can develop using Waterfall are becoming increasingly few and far between. Waterfall is best used for small pieces of work, where the risks of unknown-unknowns are lower, customer feedback is not critical to the success of the product, and there’s a very low likelihood of changes.

Additionally, if there is high clarity of the work and the development team has validated that there is low technical complexity, then Waterfall delivery may get you where you need to go.

A few years ago, I worked on a really large transformation programme where months were spent in requirement-gathering workshops, and more were spent producing 1,000s of pages of use cases, business requirement documents, and more.

Throughout development, there was very little room for requirements clarifications and scope changes, and what was thought to be a good candidate for Waterfall delivery turned out to be problematic.

The tricky thing is that we were developing products in a world where customer expectations change rapidly and new competitors disrupt the market status quo seemingly out of nowhere. So, by the time the work was completed five years later, customer needs were different to those originally anticipated.

Is Agile a golden ticket?

Many organisations are adopting Agile simply because the industry is advocating it as the golden ticket to competitive advantage and the key to survival. But, is there a way your product could still fail when applying Agile practices? Almost certainly, yes.

The most successful teams understand that to ‘do Agile’ is not the end goal. Agile is an effective way of developing software, amidst uncertainty and change, but it’s also a way of thinking that cultivates an adaptive mindset in organisations.

The built-in opportunities in Agile to regularly reflect and respond to changing environments means it’s relatively easy to add, remove or change requirements, even to change direction completely.

Returning to the transformation programme for a moment - once the Waterfall programme deliverables were completed, we realised we needed to work differently and began using Agile ways of working. We were able to start delivering customer value every three months, and then every seven weeks, and a mindset of continuous improvement was cultivated.

This meant we could care for our product in a way that wasn’t possible within strict, fixed-scope contracts, and so we:

• Created new features
• Fixed customer journeys that weren’t as good as they could be
• Analysed daily customer feedback to see which pain points we should address next
  
  

All in all, our teams were regularly making a positive difference to their customers’ everyday experiences, and as a result we were all happier.

Final thoughts on Agile and Waterfall

Waterfall’s plan-driven approach has fairly rigid stage gates to pass through and limited scope to reflect and respond. Agile, on the other hand, allows companies to evolve and adapt throughout the journey, ensuring they’re building the best possible product to solve relevant customer problems and meet the latest market expectations.

An isolated bubble of Agile teams in a technology department, without the right support and mindset throughout the organisation, is unlikely to be the golden ticket often dreamed about. However, what it will give you is adaptability, and in today’s world, that’s crucial to success.