Agile-Waterfall, is that an oximoron?

I was reading a blog post the other day with the provocative title “Agile is a Fad”, and it occurred to me that as Agile practices become widespread and almost ubiquitous, and as some company executives feel the pressure to hastily adopt Agile at any cost, a predictable backlash will ensue, especially when these organizations struggle with Agile introduction and adoption. This backlash will not only come from the leaders of these organizations, but also from Agile purists who foresee the Agile movement being corrupted by companies wanting a quick cure, and a cadre of consultants willing to sell them the magic pill.

So it comes as no surprise that some organizations are getting to a point in their adoption of Agile where they are questioning its usefulness and value. Some are even reverting to Waterfall after "failed" experiments with Agile.

Why is this happening? Agile was supposed to be the answer to all their past woes with timely delivery, customer acceptance, and quality. Yet, Agile becomes a battle of wills between the folks who championed it and those who simply wanted things done. At some point, failure to deliver a product on time leads the non-champions to the conclusion Agile methodology is to blame.

In reality, the problem has deeper roots. It originates with the reason these companies adopted Agile in the first place. Often, the product side of the house wants Agile so that:

a) they don't have to write extensive requirements upfront,
b) they can change their mind up to the point a product ships, or
c) they want to know what's going on inside of the software development black box.

On the other side, the technology side of the house often pushes to adopt Agile so that:

a) they can start designing and coding right away,

b) they don't have to sit through laborious requirements review meetings, or
c) they can show off their handy work early and often.

The fact is, Agile facilitates and supports many of these desires by both sides. Yet, a lack of understanding of the fundamental goal of Agile dooms the experiment to failure in many companies before or soon after it starts. Everyone becomes so focused on the ingredients and steps of the recipe they forget what they were cooking in the first place!

So what is the fundamental goal of Agile? The Agile Manifesto talks about 4 key principles that are highly valued:

-          Individuals and interactions over processes and tools

-          Working software over comprehensive documentation

-          Customer collaboration over contract negotiation

-          Responding to change over following a plan.

Yet, what do these principles help with ultimately? What is the key benefit of using Agile in software development? The answer is:

Facilitating Change that Adds Value at the Lowest Possible Cost.

Think about it... Your work as a software professional starts out with a feature request, enhancement, or bug, i.e. some kind of a change to the product. Everything that follows are steps to facilitate that change, whether you follow a Waterfall or an Agile approach. Yet, where Waterfall comes up short is on the questions of Value and Cost. Every feature that the customer doesn't use is a zero value change. Every delay in delivering to the customer is a higher cost change. A 100% successful Agile implementation is one where every feature added meets a customer need in a timely fashion and is built in the most efficient and cost effective manner.

A fundamental understanding by executive management, key stakeholders, and team members of what Agile is all about is the key to success in implementing Agile in any organization. The artifacts of Scrum, XP or Kanban are there to facilitate change, add value and reduce cost. If your organizations wants to use an incremental Scrum process (some call it Agile Waterfall) that works more seamlessly with organizational boundaries, go for it. If your organization wants to run one team with Scrum and another with Kanban because of the unique qualities of the products and customers serviced by these teams, why not. As long as you can demonstrate "with actual hard metrics" that you are facilitating requested changes that ALWAYS add value at the lowest possible cost, your version of Agile will more than likely be a success.