One of my colleagues, Mounir Ajam, posted a question on LinkedIn:
"We often see people with a technology background, especially those jumping on the Agile bandwagon, telling the world that we must transform to Agile Project Management. When we tell them Agile PM does not apply in capital projects, they insist it does ... Agilists, why do you think you know how to do our work?"
A well-meaning individual with an exclusively IT background responded as follows:
"You as the customer visit your house build and look through the framing that just went up. There is a window in the frame, you see that the view is better from that window now that you have the view framed.
But the window will be too small. You can now ask to make a change when its the cheapest time to make the change. It may delay the build a few days but the end result will be so much better with that bigger panoramic window. Later you would have a mass of re-work. You do not have to wait until the whole thing is complete and it's too late to change. You released value early."
I'm pretty sure they didn't understand the irony of their post. I'm pretty sure they didn't realize they were displaying their ignorance of the built environment for all to see. So let's take a look at some of the misconceptions ...
A. The example chosen was for a small, simple, almost trivial project. If I argued against agile/Agile using the development of a spreadsheet or the release of a brochure-ware website, I'm sure I would be taken to task.
B. The example leaps into the end of the project: the construction phase. No mention of the architect or the permitting. No discussion of who the owner is. Did I (as the customer) buy the house from the developer? Or did I secure the site on my own, hire an architect to design it for me, then hire a builder?
C. The example appears to assume that I as the customer was not involved in any of the design decisions. It also appears to assume that the architect never visited the site to design a building customized for the location. And it appears to assume that I as the customer never had any conversations with the architect about what was important to me: panoramic views? energy conservation? interior wall space for my collection of Picassos?
D. The example trivializes the process of changing the window design in a house that has already been framed. Two-by-fours will need to be cut and the wood removed is probably wasted. Hopefully there is no structural impact. A new window will have to be ordered. The building permit may have to be modified, and waiting for approval of the revised specs could cause serious delays. What if the delays push us into winter?
E. Even worse, what if you're building the home in Malaysia where the framing is done with steel, not wood? Changing the window design could be a massive problem.
F. The time to have made this change was during the requirements or design phases. Not the construction phase. That's when changes are most expensive. You haven't really released any value at all with this change: you've just exchanged a better view for higher costs and schedule delays.
Is there anything wrong with agile/Agile? Not really. If you're following the principles described in support of the Manifesto for Agile Software Development and using it for software development, nothing wrong with it at all. It's got a lot of good features. If you're trying to apply an agile/Agile mindset (whatever that is; I haven't been able to find anyone who can tell me where that mindset is defined or described ... or how it differs from competent project management) to intellectual work such as software development, new product development, or even architectural design, jump on the bandwagon. There's some chance you will benefit.
But if you want to convince Mounir (or me) that agile/Agile can be applied to most projects, most of the time in the construction phase of a capital project ... do a little research before you embarrass yourself.