So, let me talk about a word that crops up a lot when people are talking about Agile product development, the term “Waterfall”.

Agile (and Scrum as a subset of agile) started in Software development. But before agile practices began to take hold, people used other ways of delivering value. They often talk about what we call “traditional project management methods” and this is used alongside another term, waterfall.

So let me separate these out and give some background to allow us to better understand the evolution of agile.

Let me start with two words, Complicated and Complex. Complicated problems are hard to solve but they can be solved with rules, systems and processes. They are regarded as Predictable, in that the the outcome will be the same each time, no matter how many times you complete the action. Complex problems are different, they have a lot of unknowns and many interrelated factors. Complex problems are not predictable. Each time you try to solve the problem, the solution could be different. Solving complex problems needs new ways of thinking. Using the same methods as those we use on complicated problems just wont work.

So, let’s take a different tack. As we go back in time, starting from about the 1900’s we see that more and more of the problems we as humans were trying to solve, fell into the Complicated Bucket.This is regarded as the second Industrial revolution, with automation and assembly lines etc. By the way, if we go further back, we find that they fell into another bucket, the “Simple or obvious” bucket. So, humans have a long history of solving complicated problems. And a very good way to solve a complicated problem is sequentially. Activity one followed by activity two, three, four etc.Think of building a house, floor goes first, then the walls, then the roof, wiring, plumbing etc. You would never wire before walls, or plaster before window frames. So, project management gurus designed methods and processes to work in this sequential way to solve complicated problems.

But, probably in the last 50 years, our lives and the products we use have become exponentially more complex and so too has the building of products.And for a long time, we were stuck in a loop, trying to use methods that were perfect for complicated problems, to solve complex and adaptive problems. After a time, people started to realise that it just was not working. A high percentage of projects were failing and people started to look at other ways to work. And Agile was born out of the ashes of these failures.

Don’t get me wrong, there were other things bubbling up to the surface. In the same way that products were moving to the complex, the very organisations themselves were evolving and maturing and the very structure of organisations and the relationship between the people in those organisations were evolving. And nowhere was all of this more evident than in the world of software development.

But let me start at the beginning and introduce the word waterfall. In software development, waterfall, or modifications of it, were the traditional ways to deliver projects. It epitomizes this linear, sequential design approach. The waterfall model was first described in the early 1970s by a gentleman called Winston W Royce and the term Waterfall itself was first mentioned in a paper in 1976. In 1985 the US Dept of defence accepted it as a standard for software design. Waterfall described 6 sequential phases;

• Requirement:
• Analysis
• Design
• Development (coding)
• Test
• Operations (release, support etc)

The progress was gated so that one would complete and verify the last phase before moving to the next.

Now that I explain waterfall, many readers will be nodding their head and saying “ahh, of course I know this, we use it all the time!!” And, to be clear, this waterfall method does work. I have delivered many a project myself using it.

A few points, pros and cons:

• It is a structured approach leading from stage to stage
• It is a low maturity framework.
• It is a top down, low autonomy model with the actual teams doing the work having little power and ownership
• Done correctly, many problems will be identified early on which means that they are cheaper and easier to resolve
• It is highly structured and rigid in terms of delivery
• Its focus on documentation and control reduces risk
• Great when scope is fixed (non complex)

I could keep going with these pros and cons but I just wanted to give you a flavour.

So, waterfall was the poster child of complicated software development into the 70s, 80s, 90s but all the time, our products, even our organisations were getting more and more complex. And the bigger they were and the longer they went on for and the more complexity that arose, the more people started to question the suitability of waterfall as our development method. And through that period, this idea of a more incremental and iterative thinking started to emerge. Now, one of the interesting things to note is that the phases of building are still as fundamental today, you gather your requirements,, you analyse how, you design, build it, test it and release it. I will caveat that a lot of research and learning has been done in the phase preceding this requirements and a whole industry has cropped up focusing on “why”we want to do this, Who is our customer etc.

An interesting point is that the term waterfall was always a project management term, a project management framework to develop a product.

But today, we have moved beyond software management and we have dropped the word software from the literature. We now talk about agile product management and we also look at a more holistic and full lifecycle of a given product. While waterfall was always billed as a project management framework, so Agile and its children like scrum, are billed as product management frameworks as they are suitable for all aspects of product life.

But modern enterprises, including many of the largest companies in the world today, still use waterfall as their framework of preference. But disruption is happening in every industry, and many of the young pretenders have used agile as their sword to swathe through the competition and topple these older dinosaurs. And it is not going unnoticed. Many of these dinosaurs are actively pursuing agile agendas. Some are succeeding, and some are failing as they learn that it is now simply about a framework, it is about an evolution in everything that you hold true!

That’s all folks!

Dave