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
softwareproducts (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.
Pat Weaver
Lynda Bourne
Mosaicproject's Blog 
To quote Thomas Sowell, “One of the most important reasons for studying history is that virtually every stupid idea that is in vogue today has been tried before and proved disastrous, time and again.” https://www.azquotes.com/author/13901-Thomas_Sowell
Given that people have been “initiating, planning, executing, controlling and closing” projects for well over 6,000 years, do our IT colleagues REALLY believe they have “discovered” something “new” with their “Agile Manifesto?”
Go to the Stanford Encyclopedia of Philosophy and see what they say about the history and evolution of the “Scientific Method” https://plato.stanford.edu/entries/scientific-method/.
Then go HERE and see a very nice summary of the 5 attributes of the scientific method https://sciencing.com/five-characteristics-scientific-method-10010518.html
1) Empirical,
2) Replicable,
3) Provisional,
4) Objective and
5) Systematic.
Then go HERE to see a graphical description of the Scientific Method PROCESS MAP- https://www.sciencebuddies.org/science-fair-projects/science-fair/steps-of-the-scientific-method.
Then compare these references against the “Agile Manifesto,” and all you will find is a more “woke” version of the “Scientific Method.”
This raises the question about PMI’s PMBOK Guide 7th Edition. Why not just adopt the attributes and process maps of the Scientific Method? It has been around for over 1,000 years, starting during the Middle Ages with Physicist Ibn al Haytham in his Book of Optics (1021), followed by Albertus Magnus (1206–1280), Thomas Aquinas (1225–1274), Robert Grosseteste (1175–1253), Roger Bacon (1214/1220–1292), William of Ockham (1287–1347), Andreas Vesalius (1514–1546), Giacomo Zabarella (1533–1589) Galileo Galilei (1564–1642) and Francis Bacon (1561–1626) and has brought humankind hundreds of thousands of new products, services, and knowledge, including Edison’s electric lights, Bell’s telephone and Fleming’s discovery of Penicillin to name but a few?
So when are organizations such as PMI, AIPM, IPMA, AACE, et al. going to stop trying to claim “ownership” of the “body of knowledge” and simply go back to find what we know has and hasn’t worked over the past 6,000 years and then update or adapt these “tools, techniques and processes” to reflect today’s technology?
PS If you go HERE https://build-project-management-competency.com/1-4-1-1-unit-1/ and scroll down to Figures #15 and #16, you can see how the Scientific Method applies to the Integrated Asset, Portfolio, Program (Operations) and Project Management Methodology first made public by either Esso or Diamond Shamrock Oil back around 1955 and attesting to the fact it actually WORKS, is still in use today, 65 years later, by all the Major International and nearly all National Oil Companies today.
There is no shortage of “best tested and PROVEN” tools, techniques, and methodologies out there, noting that simply claiming whatever they are pitching cannot and should not be labeled as a “best practice” until/unless there is PROOF to support that claim, as required by US and most other countries “Truth in Advertising” regulations. https://www.ftc.gov/business-guidance/resources/advertising-faqs-guide-small-business
In my experience, the traditional way of managing projects, can deliver with the right skill levels. Uncertainty does increase with uncertainty and applying integrated risk management is meant to address this. Rolling wave planning takes care of changing environment as well.
Agile, is a great philosophy especially in software development were project failure is at its highest but if traditional PM is executed with the right skill level success rates should increase.
Also note that failure rate as defined today maybe controversial considering that some projects that were considered a failure in terms of project management efficiency turned out to be a phenomenal commercial success for example the Sydney Opera building.
Isaac Muchenga (MSc Project Mgnt, UCT)