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:
- 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.
- My points in these posts are from capital projects perspective and how Agile is NOT the right approach to use – for capital projects.
- 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?
Mounir — in general, I agree with the premise of this series of posts: most Agile approaches are not relevant or useful for capital construction. And so I expected to agree with this post as well, but I think you have misinterpreted the principle.
True, this principle **is** most relevant for software development. But it also applies to the architectural and engineering phases of capital construction. So when you say it doesn’t apply to “capital construction,” you have to limit that assertion to the construction phase.
I also see a major difference between “welcome changing requirements” and “do whatever the customer asks.” Changing a 20 story building into a 30 story building would clearly be a challenge. All agile is saying is “look at it; consider it; don’t reject it out of hand.” More than 40 years ago, MIT students investigated building a building from the top down by constructing the higher floors first, then jacking them up. Such an approach might allow a way to accept 10 more floors.
But even in software development, some changes in requirements cannot easily be met, and the implications of the change must always be communicated to the owner/ buyer/ customer.
Hi Bill, thank you for feedback. Two points to keep in mind.
(1) If you go back in the series, I clearly distinguish between agile approaches as in agility, flexibility, and adapatability and state that these are common practices in any environment and are part of traditional (proper) project management) and not limited to agile – agile or Agile is claiming these practices as their own and often in a way that they invented them and “traditional” is bad and does not work.
(2) I also state that many agile/Agile principles can be used on all projects but in capital projects their use is limited to certain aspects of the project and NOT as the main method/approach.
regards