This is the third article on Agile.

1. The first one covered a discussion on LinkedIn and summarized the key points discussed.
2. With the second article, we started to demystify the concept that Agile is for most projects most of the time. In this second Article, we highlighted the overview mission of the Agile Manifesto.

Today, we will start covering the various principles, or at least one of them. With each post, we will explain why we think Agile does not work for capital projects and possible other non-software development projects.

The Agile Principles

The following link is to the Agile Manifesto – twelve principles.
Three key points here:

1. By Agile we mean things like what is addressed in the Manifesto and not as in agile – meaning agility. This is not a critique of the Manifesto or Agile (with capital A) since it is clear the Agile Manifesto is about software and here, we are not talking about software – see point no 2.
2. My points in this post (and future posts) are from capital projects perspective and how Agile is NOT the right approach to use.
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 first principle

The first principle is: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
It is about software, so do we need to talk about this?
Well, let us try.
Can we apply this principle to ‘building a house’ project? We will keep it a simple project. Today, I am ignoring the full project life cycle for a “House Project”, which include various stages. The stages would be feasibility, requirements, architectural design, detailed engineering, construction, handover – acceptance, and close. In the following example, we are only focusing on one stage – construction.
To build a house, we have to clear the site, first. So, when this work is done, do we hand over the site to the client for ‘”early and continuous delivery?”
How about building the foundation? Do we hand it over for customer satisfaction?
How about the structure, or the electrical system?
The customer does not want to be involved in this detail and hand over every piece – it DOES NOT ADD VALUE. Of course, we still have the quality assurance and other control aspects happening but we do not have “continuous delivery of components“.
Sure, we do not have to specify the paint colors upon contract award or maybe the type of ceramic in the bathrooms. We decide on these when it is time to decide. In that case, is this Agile? Does it mean that building the house is an Agile Practice?
In villages in Lebanon, many people overdesign the foundation and main structure as they build their homes (we use concrete). Why? Because in the future, their kids, can build their own homes as a second and even third floor. Is this Agile? If it is, we can say wow, an Agile project that spans a generation 🙂
We would love to hear from Agilists how this specific Agile Principle applies on a simple project, like the one we discussed here.
The rest of the principles will be in future articles.

Closing Comments for today

A great or even good project manager AND PM personnel in organizations with good PM Maturity, know that project management is adaptive. They know that project management methods have to be tailored and custom fit to the type of industry, organization, or even divisions within an organization.
Some projects require many phases, others only a few. Some organizations have a stage-gate process, others not as rigid. Yes, we can build a house in increments over many months or even a generation, as discussed in the Lebanese example. Yes, we can build a residential community house by house or a block of houses at a time. These are normal, business and market driven practices that we have used for ages. So is it trendy now to call these Agile Practices?
What we are observing is that Agilists are taking (adopting) some good ole traditional project management practices and claiming them as their own – then criticize traditional project management and blame it for projects’ failures.
We have got to go beyond Waterfall and Agile, Iterative or Incremental.
This is one of the main reasons we had developed CAMMP™ (The Customizable and Adaptable Methodology for Managing Projects™) back in 2007 and have been publishing about since 2010; including Project Management Foundation, Redefining the Basics of Project Management, and Applying Project Management.

Your Thoughts?
[contact-form][contact-field label=’Name’ type=’name’ required=’1’/][contact-field label=’Email’ type=’email’ required=’1’/][contact-field label=’Website’ type=’url’/][contact-field label=’Comment’ type=’textarea’ required=’1’/][/contact-form]