Over the last couple of months, I’ve seen many discussions around the concept of agile in project management where it seems no one was talking about the same thing…….. This set me thinking.
My conclusion is the Agile Manifesto sets out a philosophy not a methodology and change the term ‘software’ used in the manifesto to product (or output), it is a generally applicable philosophy. Then there are various methodologies for implementing this philosophical approach. This distinction creates to totally different areas of discussion. One is the validity of the philosophical ideas, the other the appropriateness of any given methodology in the circumstances of a particular project.
The underpinning philosophy driving the development of project management from the 1960s through to the 2000s was derived from scientific management, the core elements being:
- The future is largely predictable and we can create reliable schedules and budgets for a project.
- These plans can be used by management to control the work of the project.
- Risk is important, and if you do enough work, you can parameterize the overall risk profile and allow appropriate contingencies based on the management’s risk appetite.
- When things go wrong, someone is at fault.
- The way to improve project outcomes is to do ‘project management better’.
Then the Agile Manifesto was published. It sees most elements of traditional project management as valuable, but places more emphasis on:
- Individuals and interactions,
- Working
software products (fit for purpose),
- Customer collaboration,
- Responding to change.
These ideas are consistent with other innovations such as empowerment, self-managed teams, and stakeholder engagement which also emerged into prominence in the 2000s.
This ‘agile philosophy’ represents a paradigm shift in thinking from the older project management ideas that are built around predictability and ‘command and control’ to one focused on delivering value to the client by working with people.
A third concept, also from the 2000s, is complexity which emphasizes the impossibility of predicting future outcomes, the day-to-day actions of the project team build the future within an ever-changing environment.
My feeling is at this level most thinking project practitioners will be willing to agree agility and complexity are important elements in the successful management of projects.
Then you get to the methodologies. Scrum is a methodology developed for use on soft projects (software development, and others). It emphasizes using the skills and capability of the project team to decide what to do next. Lean construction also emphasizes using the skills and capability of the project team to decide what to do next. The difference between the two is the characteristics of the product places far more constraints on the work of the construction team, compared to the software team, and this is reflected in the methodology.
Separating the discussions around approach (philosophy) between predictive, agile and/or complex is important for the evolution of project management as a concept. But this is a different discussion to the one about which of the methodologies is best for a particular project. In this respect the agile community are well ahead of the more traditional project communities. Agile methodologies include Scrum, DA, Safe, XP, Kanban and several others.
In the more traditional industries, we have a few concepts such as Lean Construction and BIM, but mostly continue to approach the management of projects in the same way as we did in the 1970s, 1980s, 1990s, etc. And continue to see the same failure rates, and continue to blame people, or the lack of skills, or the lack of diligence in the planning……. Maybe there is a need for a reframing of the discussions.
Posted by stakeholdermanagement 
Lynda Bourne
stakeholdermanagement
Stakeholder Management's Blog 