Tagged: waterfall

Poem for The Waterfall Organisation

WaterfallThe Waterfall Organisation. Smashing things on to rocks and down great distances with much spray and noise, but to what effect? The Bottom?

Fishes, swimming in the stream. Oblivious to the waterfall for they live in the flow.

But there is life beyond the stream, beyond The Waterfall.

The fish know this not. The Stream knows this not. The Rocks and Water know this not.

Will they learn? That The Waterfall exists within The World which exists within The Universe.

How small The Waterfall is…

Everything you think you know about Waterfall development is (probably) wrong

Well, according to the guy who wrote the original paper at least. What follows are some rather cheeky comments from me and some copy / paste of some diagrams from the original paper along with some text from

Waterfall Accident: The waterfall model is not what we think it is

What we today know as the waterfall model comes from a paper with the title “Managing the Development of Large Software Systems”, written in 1970 by Winston W. Royce. On page 2 it contains the famous diagram with the cascade starting at “System requirements” on the upper left, continuing on through “Program Design” and “Coding” down to “Operations” on the lower right.


But nobody seemed to notice that Royce does not promote this model… He then goes on to promote a different process – he recommends to “do it twice” by building a throw-away “pilot model” first to explore novel elements and unknown factors.

By now you may be thinking this is some clever photo-shopping, but it’s not – I just put some text in red, the arrow, box and blew up Royce’s original text which really is written underneath the diagram. Don’t believe me? Read a PDF of the original paper. Do you think the paper is a hoax? Then try googling “Managing the Development of Large Software Systems pdf” and read any scan – they all say the same thing!

Are you in shock? Most (waterfall) people are when they are first exposed to this (I’ve literally seen people stagger backwards) because it says that the waterfall model is fatally flawed, risky and prone to failure. Yet we’ve been told the opposite throughout our education and careers: “the waterfall model is boring, a bit long winded, but safe”. But it’s not – it’s “risky and inviting failure”!

“Ah, but we’ve refined it through years of experience and it works now” you may say. I’m afraid not – report after report shows a high failure rate for large IT projects (mostly of which are implemented using Waterfall). For example a recent McKinsey / Oxford report, referred to by Gartner said

Half of IT projects with budgets of over $15 million dollars:

    • Run 45% over budget
    • Are 7% behind schedule
    • Deliver 56% less functionality than predicted

Remember, this is not your fault if you didn’t know about this. It’s been one of the biggest mistakes / cons in the software industry depending on which view you adopt. The big question is what are you going to do about it now you do know?…

Well that’s easy, just go to the next page on Royce’s paper where he outlines iterative development:


Yes, that’s right, Walker Royce, acknowledged as “one of the leaders in software development in the second half of the 20th century” essentially invented Iterative Development* and not Waterfall in 1970 over 40 years ago. If only people had read the paper fully and looked at the diagram after the first one.

But maybe you want to go further? There’s a whole world of Agile, Scrum, Kanban and many other things that await you. The rest of the industry has been working away…

* He refines the above to “Do it twice”. Iterative Development as outlined by the Open Unified Process is really “Do it n”

PS There’s a large lesson in effective communication too… it’s the old classic of summarising your conclusion first, lest someone interpret your first step of reasoning as the actual solution as in this case.

Agile Dependency Management

So if you’re following this blog or about to, you should realise that I’m not a daily blogger. It depends on how much time I have, so there will be gaps and there will probably be periods of manic posts if I get fired up about a few things (which if you follow me @RiczWest on Twitter, you’ll know I can! :)

Anyway, to the problem at hand which is one that came up recently. The environment is mainly Waterfall, with some projects partially Agile. There is quite a bit interest in “Agile Techniques” though.

Personally, I’m a big believer that you can use some Agile techniques without causing “cognitive dissonance” and blowing people’s heads up ;-) I’m very much a “whatever tool suits the job and the context” kind of guy – I live in the probability clouds between absolutes of anything.

Out of the blue, a colleague asked me if I “Knew anything about Agile?”, “A bit and I’m a Certified Scrum Master” I answered… “Then how do you manage dependencies in Scrum?” was the next question. I gave the classic response of how the process and the team deal with this because they’re empowered. “Yeah, we can’t do Scrum, but is there some Agile technique we can use?” he then asked.

“Well, you could take your Tasks, put them all on sticky notes and use grouping and discussion to work out what the dependencies are” I replied. “Yeah, that sounds good” he said, “but we’ve got teams distributed geographically and across multiple vendors” ooohh – sharp intake breath from me… hmm…

After a bit, the Scrum of Scrums popped in to my head so I suggested that each “area” could do the dependencies for their bit as originally suggested and you could then get some people from each “area” together to work out what their global dependencies across the whole project were in the same physical location. “Is this possible?” was my next question. “Yeah, I suppose we could do it for a day” he said without much hesitation.

So that’s where I am, but I have a few questions that I value people’s input on:

  1. Am I a crazy idealist? Is this pushing the boundary too far and should I just say “you can’t use bits of Agile like this as the risk is too high”?
  2. Does the “overall process” make sense? Any tweaks, alternatives, whatever?
  3. In the Dependencies of Dependencies workshop we could have, how many should come along from each area? My guess is that there are probably around 5 “areas”
  4. Does this have any chance of working? Or will it just blow up and become a “yeah, we tried Agile and it didn’t work” kind of thing?

As you can hopefully gather, I’m really not precious about this, but view it as a “potential opportunity” to get people to take a few steps “outside Waterfall” as they’re already thinking about it.