Joined :
31 January 2012
Blogs :33
Sunday, 22 March 2015
0/5 (0 votes)
Can we Banish the word Waterfall?



When systems people talk about “waterfall” approaches, they mean something like the picture above.

But “Waterfall” is an ancient myth!

It is a myth especially perpetuated by people who want to promote some other school of thought with a catchy name. (“If it’s not strictly _____ it’s therefore Waterfall – and we all know that’s evil!”.)

When have any of our readers actually seen this picture in a methodology in reality?

Well actually I did once, in the 1970s when I was just a youngster. Management at my employer was quite concerned about predictability of costs and schedule. And it was struggling to keep business in control of systems. So they acquired a paper-based methodology. When it was tailored and deployed, it required the systems people to get specific forms signed off before they could proceed to the next step. It truly was “finish to start” for all significant decisions. And it was “one size fits all”. The same forms had to be used for every project over a moderate size.

It was a failure. Projects took longer mainly because of delays in approvals. Systems people also struggled with sections of the forms that didn’t quite match their project so they were less productive. And the morale of systems people suffered, because they felt seriously restricted and impaired.

Over time, details were quietly dropped although they kept a few major decision stage gates.

My employer at that time was not alone it this attempt. There was a whole generation of systems people who carried their scars forward and passionately cautioned the next generation to beware of any formal methodologies.

But the reality is – we haven’t seen true “waterfall” methods since those early days. From the 1980s all major thought leaders have been promoting concurrent engineering, iterative approaches and encouraging prototyping wherever it’s feasible. And we’ve seen promotion of many other “anti-waterfall” principles, all under many different labels.

How about Macroscope?

Macroscope has never been a waterfall approach. One could always apply a waterfall mentality with Macroscope if that’s really what the business needs, but that would just be a case of adapting to the real world.

If you look inside, you’ll see that the fundamental principles of Macroscope include:

  • Adapt to your context
  • Aim for flexibility, agility and reusability
  • Aim for quality and continuous improvement (with a sub-bullet on prototyping)
  • Apply concurrent engineering

When you drill down into any of the process descriptions and guidelines it becomes completely obvious how these principles are implemented.

Macroscope has always encouraged us to be as agile as we safely can under our particular circumstances. We’ve always treated agility as a matter of degree, not a binary condition. The main determinant is the client’s approach to decision making.

So have I missed something? Do you see some waterfall aspects in Macroscope? If so, I really encourage you to post a reply. Who knows – since Macroscope is always under continuous improvement, you might see something in Macroscope that needs improving!

2295 view(s)


0 #2 Amarjeet Kaur 2017-05-29 19:58
can you explain how macroscope support waterfall methodology
0 #1 Janet Williams 2016-10-25 12:35
"We’ve always treated agility as a matter of degree, not a binary condition." So true!

Too often in my experience, Tom, and I imagine in yours as well, Agile is an excuse for teams to forego ANY methodology. However, that is also a corruption of the intent of Agile, just as Waterfall is a corruption of the intent of Macroscope. "Agile approaches help teams respond to unpredictabilit y through incremental, iterative work cadences and empirical feedback." (

By this definition, we should be quite compatible.