Tag Archives: waterfall

Agile is NOT new and not enough

So people keep talking about the Agile – Waterfall dichotomy. About agile and un-agile practices. I decided to have an unscientific look at what Agile isn’t. If there is a true dichotomy between Agile and Waterfall, then things opposite of Agile should be either entirely out of scope for projects and software development or they should be characteristic of Waterfall methods. And since anyone would bother to mention them in the context of Agile, one would assume that this would be because they are distinguishing between Agile and Waterfall. Continue reading Agile is NOT new and not enough

My Journey towards Becoming an Agile Driver

What’s an Agile Driver? I have always been driving kind of ad hoc. Getting from A to B with no particular plan. If I were a programmer you would call it “cowboy coding” but I’m not, so we can call it “cowboy driving”. People, everyone it seemed — my boss, my wife, my children, the odd passengers — were all complaining that I needed to use sound engineering principles and state of the art equipment to improve my driving skills. “It will help you get from level 1 to level 2 or even 3 as a driver”, they said. Continue reading My Journey towards Becoming an Agile Driver

A Waterfall is Fine – for Watching

As humans we love the majesty of nature. Who can fail to be impressed by such majestic cataracts as the Niagara falls or the Victoria falls? Someone said that falling is fine, it is hitting the ground that kills you. Same thing with the water in the waterfall. When it hits the end, enormous chaos is generated both visibly as spume and invisibly in the water.

Hydroelectric Power

We do not usually try riding a waterfall in a barrel. We can harness it for electric power. But if we do, we certainly do not want to ride it in a barrel.

Agile is also a Waterfall

Two pipes, one with laminar, one with turbulent flow as in a waterfall.
Laminar versus turbulent flow. Image reused from http://www.ceb.cam.ac.uk/pages/mass-transport.html .

Agile software development methodologies are about breaking the waterfall into safe, manageable steps. The impact is not saved for the end in a big bang delivery. Instead it is taken one step at a time. The water does not flow as chaotically. It is more like a laminar flow.

Waterfall got it right… almost

I am not going to write a lot on waterfall versus agile but… An interesting point that is worth reiterating. Waterfall software development processes can remind us of many of the important steps in software development. The difference is not so much in what we do as in how, when and what order.

Waterfall, Agile and the Construction Industry

When people ask me to explain the difference between agile and waterfall methodology I usually give an analogy based on the construction industry:

The Construction Industry as “Waterfall Heaven”

  • When you are building a home it is often quite possible to know in advance exactly which steps to take and in which order. You simply cannot start with the roof, continue with the walls and finish with the basement. You cannot apply the wall paper before the walls. Furthermore, you can easily predict how much time is required for applying X square meters of wall paper, or Y roof tiles etc. There are manuals available for project managers containing a wealth of data on standard work and its cost etc. In effect, it is possible for a competent construction project manager to create a plan for a project like this and to follow it with no small chance of success.
  • In software engineering on the other hand, things are a lot more difficult to predict. You cannot know in advance how long it will take to implement requirement X. This is because you are not assembling house number 1000 in a long line of identical houses. The whole idea of software engineering is to take something which is more or less unknown and transform it into something well known. So while designing the software is not really a predictable process impressing it on a CD and shipping it is.

Risks Levels Have Increased

Well, it turns out that the construction industry is not all that predictable anymore either. According to Everts et al. a lot has happened in the construction industry in recent decades. Where there used to be 70% of construction taking place on virgin land at the edge of the city with relatively predictable conditions there is now 70% of construction taking place in already built-up areas with of course a much higher level of unpredictability. Also, at least 50% of construction work is not new buildings but repairs, remodelling and the like. Working with old buildings is naturally much more prone to surprises, just like working with old software…

Tightening the Waterfall or …

So far, the response of the construction industry have been to increase bureaucracy by generating more paper work for incident reports, change requests etc. If you are in the software industry, you will recognize this instantly…

… Move to Agile

Everts et al. takes things one step in another direction by surveying which skills would be needed and/or are lacking among construction project managers and building project managers in order to be able to work in a more agile way. They lists skills such as:

  • Negotiation skills
  • Cultural awareness
  • Conflict management

Conclusion – Not a Waterfall any Longer

Skills which are equally useful for a software engineer or manager! And that’s not all. With smart buildings the software component of the construction work is increasing. Intelligent building of intelligent buildings will be a new and major challenge for the construction industry. I guess I will soon have to switch to another example when I want to explain under which circumstances a non-agile project management style is most appropriate.

References