Busting the myth of Agile for most projects, most of the time – 3

Another article on Agile and busting the myth of ‘Agile, for most projects, most of the time.’

In this post, we are covering the second principle from the Agile Manifesto. The following link is to the Agile Manifesto – twelve principles.

Before you read

Three key points to note before you read:

  1. By Agile we mean things like what is addressed in the Agile Manifesto and not as in agile – meaning agility, adaptability, etc. This is not a critique of the Manifesto or Agile (with capital A) since it is clear the Agile Manifesto (and Agile) is about software and here, we are not talking about software – see point no 2.
  2. My points in these posts are from capital projects perspective and how Agile is NOT the right approach to use – for capital projects.
  3. Of course, in any project, even capital projects, some elements of Agile could be used – but these are minor and a fraction of the work required – so we cannot take a fraction and pretend it is the whole.

The second principle

The second principle is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Although the word ‘software is not mentioned here’ it is implicit that ‘development’ refers to the development phase of a software development project.

Once again, in software development projects this might be perfect. Keep in mind that I am not an Agile expert nor a software development expert so I cannot offer a professional opinion for the use of Agile in this type of projects.

Remember, the focus of this series of articles is capital projects (petroleum, real estate, industrial, infrastructure, engineering, and construction).

For Prrinciple Number 1 we use ‘building a house’ project.

Let the next picture speaks. This picture has been used in numerous resources on project management; yes, traditional project management.

The bottom axis represents the span of time on a project from start to finish. By start, we mean initial approval of the project; not the start of “execution”, “development”, or “implementation”.

The red curve is what we want. This is not theory – this curve is based on years of historical projects information. It clearly demonstrates that as we introduce change along this project life cycle, the cost of change increases dramatically as the project progress. Sometimes the change is exponential.

Just imagine you are building a 20-story tower and you are already in construction (development in the software world) and the owner decided to make it 30 stories. Most likely, this would not be possible if the tower was designed properly for 20 floors. Maybe we can add 1 or 2 floors without risking the whole structure but 10?

Or, the owner decides to make the plot space bigger by 10, or 20%. Not possible.

Even if the owner decides to go down from 20 to 10 floors, that might be possible but it would result in wastes, since a great deal of resources would have been used on the foundation and the main structure to withstand a larger building.

Let us consider another project, a highway or metro project. Imagine that the authority developing this highway or metro as they progress. Buying the right-of-way, clearing sites, designing, building as the project progress. We are likely to end up with curly fries :). Do you want mustard with that? 🙂

Closing Remarks

Back to the Agile Principle, does this “Agile processes harness change for the customer’s competitive advantage” really possible on such projects? Or, is “Welcome changing requirements, even late in development” a recipe for failure or even disaster? I hope that the project owner has deep pockets to avoid bankruptcy.

The Construction Industry Institute has best practices on change, and its various studies tell us the same story as the image above. Even more, a CII study shows that significant changes EARLY, in engineering, will have significant impact on construction productivity; and in turn cost and schedule. Project overruns and delayed projects; have direct impact on the project’s realization of benefits (read “competitive advantage”).

We would love to hear from Agilists how this specific Agile Principle applies on projects, like the one we discussed here.

Your Thoughts?