Can you use a Waterfall process and still “be agile”?

A couple of days ago I tweeted a seemingly random thought:

“Waterfall is not the opposite of Agile. An organisation may use a waterfall process and still be agile.”

Now, I completely accept that within twitter’s 140 character quantum this could be easily misconstrued. What I was trying to say is that we can still have a single-pass, stage-gated process (like our waterfall metaphor) and still improve or increase agility.

The genesis for the thought came partially from a comment made by one of the reviewers of a session I proposed for Agile2013 conference. The comment was regarding two simplified Cumulative Flow Diagrams (CFD) highlighting before and after we made some simple changes to the way a team of 50 worked on a core legacy system.

Before: Cumulative Flow Diagram

Before – Feast and Famine

After: Cumulative Flow Diagram

After – Smooth Sustainable Flow

The reviewer made the following comment about the “after” CFD:

“[The after diagram] visually looks like overlapping mini-waterfalls with equal time for scoping, design, development and test. Some – and maybe many – folks in the community would not consider such an approach to be an example of increased agility”

And yet, here are the results:

Speed:

Results – Faster Delivery

Quality:

Results – Better quality

Value:

Results – More Value

So, more value, significantly faster end-to-end, and with better quality. And yet some folks in the community would (apparently) not consider this an example of increased agility. Hmmm…

I accept that the process is still waterfall – intentionally so. Instead we left their process largely intact, put Work-in-Progress limits in place and changed the order of some key tasks around so it was more test driven. But we mostly focused on addressing issues caused during the fuzzy-front-end. We made no changes in engineering at all due to the exorbitant cost of retrofitting over 7 million of lines of code. Colocation wasn’t an option. Introducing Scrum would have caused havoc.

The question I have is quite simple: has this increased the agility of the organisation?

I did get some feedback from the twitterati about my apparently mad statement (accepting that twitter seems almost designed to create misunderstandings).

Someone even went so far to kindly provide me with what they felt was the definition of Waterfall and Agile:

Waterfall = big batches + no feedback + late learning

Agile = baby steps + early feedback + fast learning

Perhaps I’ve no idea about this stuff – but I’m not so sure that either of these terms are that well defined. (I get that twitter’s quantum makes this difficult).

The term “Waterfall” supposedly comes from Winston Royce’s 1970 paper. The problem is, that Royce doesn’t even mention the term waterfall in the paper. Neither does he describe such an inflexible process. The other potential originator, Barry Boehm, denies originating the term too. In reality, “Waterfall” is mostly a straw man, constructed by consultants and coaches as a non-existent alternative to their proposed solution. Quelle surprise!

Wikipedia defines the Waterfall model as such:

The waterfall model is a sequential design process, often used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

So, according to this definition (feel free to provide a better source in the comments), the waterfall model is a sequential one-way development process. It does not specify big batches, or zero feedback or the requirement for learning to be late. Of course it doesn’t! That’s just a straw man diversion built up in order to knock down and claim a non-existent victory.

Defining Agile is similarly problematic. At least we have the Agile Manifesto to guide us, but famously those signing the Agile Manifesto didn’t manage to agree anything beyond the four values and the 12 principles. Neither of these mention baby steps, early feedback, or fast learning (although those may be the outcome). My issue is not with the definition, it’s more that there is supposedly an accepted or orthodox dogma that, if I don’t agree with it, I must be mad!

Which brings me to my tweet moments later (in an attempt to clarify what I was getting at) proposing the following:

Thought experiment: You use a single-pass, stage-gated process with an e2e cycle time of 1 week.  Are you “agile”?

And a clarification:

The work you are flowing e2e could be iterations (i.e. rework) or increments. 1 week feedback loop.

The point I was trying to make is that, Agile and a Waterfall process are not opposites of each other. You can use a supposedly waterfall process, and still have some measure of agility.
On top of this, “Agile” is not a binary, yes/no condition. Your organisation as a whole (not just IT) can only be more or less Agile. This immediately raises a question: how might you objectively measure this? My view:

The absolute zero of Agility is an e2e cycle time of infinity.

There are plenty of teams, projects and organisations who use Scrum or some other flavour of Agile and yet their cycle time from the lightbulb moment (when someone has an idea) to when that idea is rendered in working software in a live, production environment is measured in months or even years.

My simple suggestion is this:
One of the key measures of your organisation’s agility is your cycle time from Lightbulb to Live — regardless of whether you follow a single-pass, stage-gated “waterfall” process or not. So, I would maintain: waterfall is not the opposite of agile.

Comments 3

  1. I concur with how this illustrates the vacuity of the general use of the term “waterfall”. My late and great friend Grant Rule used to rail again the term with regularity. He much preferred that folks use the phrase “batch and queue” instead of “waterfall”. With an awareness of the size of the batches (and queues) in any given situation. Is Agile batch-and-queue? Scrum certainly is. (Batch and queue size = circa two weeks’ worth of stories). Even Kanban could be so described (batch size dependent on release policies, queue size dependent on column WIP limits). FlowChain proposes a batch size nearer to one story, queues being moot (both driven by e.g. the economics of Flow, not least. cf. Reinertsen).

    HTH

    – Bob

  2. P.S. I feel frustrated by your blog’s (byzantine) commenting process – it fails to meet my need for something simple and quick and well-designed. I won’t be leaving any more comments here :(

    [Ed: Responding to Bob Marshall’s feedback I have moved this Blog to a new platform and hopefully the commenting process is now easy and faster. Not sure about well-designed. Feel free to leave additional feedback on that :) ]

Leave a Reply to Agustin (Cucho) Villena Cancel reply

Your email address will not be published. Required fields are marked *