18. July 2014 · 4 comments · Categories: Agile

The Agile story, at some levels is a rosy one. A Manifesto that stipulates a set of values, a collection of principles that underpins these values and teams of people of different skills working together in collaboration and harmony to deliver value in the most efficient and lean way.

Behind the scenes however, organizational politics, power games and internal manoeuvring have the motive and the opportunity to use some of these values and principles in a manner not intended for originally.

Take for example the following principle:

We welcome changing requirements, even late in the development. Agile processes harness change for the customer’s competitive advantage.

On the surface, and taking this statement at face value, this is a deceleration aimed at celebrating the flexibility and adaptability of agile teams to the ever-present changing requirements. Being able to change direction and support the business in a changing landscape is one of the areas where Agile and Lean provide better value for money. This, however, assumes that people are playing it fair and this, I suspect, is a big assumption to make. If there is anything we’ve learned from behavioural economics is the fact that what you see is not necessarily what you get. Put differently, people’s behaviour is seldom rational and even when it is, one person’s rationale will not be the same as the next person, even when they shout the same slogans.

The agile principle of adapting to changing requirements can therefore be used as a pretext for pretentious commitment to a certain scope with a hidden agenda to water down that scope citing ‘being agile’ (i.e. being adaptive to changing circumstances) as the reason for that subsequent (and pre-meditated) change. This is a level of gaming the system that is often hidden from the team members and is played by competing sponsors and stakeholders. Not wanting to be seen to be lacking in support to a certain idea they provide a lip service with no intention to seeing this going through to a completion.

So what does it really mean:

At the practical level it doesn’t mean much. Sponsors and stakeholders have always had the capacity to disturb (or enhance – depending on your view point) project direction. Agile, nevertheless, provide such behaviours with a ‘get out of jail’ card. It provides a level of legitimacy that now turns such attitude into a perceived win, a perceived ‘good behaviour’. Lack of commitment could be seen by the wider community as a sign of intense agility and adaptability – clearly not in the spirit of the agile intent.

Think about it!

Print Friendly

Related Post

Is The Time Ripe For The Agile Revolution? One of my favourite books (and films) is "The Lord of the Rings". There are many situations presented in this book which make me pause, think and cont...
All About Awkward Agile Thinking People love slogans. They love slogans because they need something to hang on to. A stake in the ground, a beacon they can point their sinking ship to...
Implementing Earned Value Management in Agile Introduction The purpose of this article is to illustrate the way in which the Earned Value Measurement (EVM) approach is introduced into an Agile de...
Let’s Be Serious About the Agile Manifesto The Agile Manifesto states that: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we ha...


  1. Hi Shim,
    Looking this through the eyes of a construction project manager, the concept of “Agile” is not a project at all but a program…..

    As project by definition has a “defined start, a defined finish; is constrained by resources and is undertaken to create a unique product, service or business results” (Wideman) it implies that, given the constraint of having a limited number of resources, that within that start and stop there is some finite amount of work to be done. (With the time constrained and the resources constrained, mathematically, there is only so much work that can be produced in that period of time)

    Given in Agile the scope continuously changes, which implies that with the scope changes comes time, cost and perhaps quality impacts, how can an Agile project possibly finish within a pre-determined start and finish date?

    To move from the theoretical to the practical, I am coming from a background in construction project management. It is near impossible for me as a builder to contractually commit to a cost budget and time of delivery only to have the owner continually making changes. Do they do it? Yes of course, but inevitably, these kinds of projects end up in arbitration or litigation. Why? Because sooner or later, the contractor is going to be seeking more money. Simple as that.

    Bottom line- Sorry, but I think Agile while a reality of life in some industries, should NOT be called project management but more appropriately, program management. (For definitions of “Program” I cite the research of Sergio Pellegrinelli as published by the Global Alliance for Project Performance Standards (GAPPS) http://www.globalpmstandards.org/main/page_program_manager_standard.html)

    Dr. PDG, Jakarta, Indonesia


    • Hi Paul, thanks for your comment.

      A lot to say in response but I will try and be brief.

      Agile is not a project management methodology but rather a set of values and principles. Most projects applying these principles are also applying Lean concepts in order to manage work in progress and optimize throughput through the ‘production’ process.

      Also, the context of my post (and I should have made it clear) is primarily software development related (though I have seen this type of behavior in non-software projects [not construction]) projects. The point regarding program vs project management is probably a result of applying the wrong terminology to this domain (as I outlined above). While some literature exist regarding the application of agile in the construction industry I suspect they really mean Lean concepts. I am not aware of agile construction projects and I can’t imagine how that would work any way.

      Happy to be corrected.

      Cheers, Shim.


  2. Hi Shim,

    Agile methods are not a cure for for inept management. Similarly, inept sponsors should not be a reason to shun Agile methods. An organization that can trace its failures to people in authority has a governance problem, and no project framework or methodology will cure it.


    • You’re right mate. Just wanted to point out that Agile provide an inadvertent way for people to ‘wash down’ their commitment by using the very Agile Methods (i.e. adaptability to changing circumstances) as an excuse for their lack of initial commitment.


  3. Pingback: New PM Articles for the Week of July 14 – 20 - The Practicing IT Project Manager

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: