PRINCE2 Agile - really?

AXELOS has published an extension of PRINCE2: PRINCE2 Agile. Many think they are two polar opposites, PRINCE2 - symbolizing control, accountability, order – and agile – symbolizing self-organization and equality. And they are polar opposites. But for very different reasons. They are opposites because real, proper PRINCE2 is very agile and the Agile movement is based on old-fashioned ineffective command and control.

Agile: Fixed Time and Cost

For anyone who wants to see it, there is plenty of proof that one of the most important reason for failing projects is in fact the focus on time and cost as demanded by the old-fashioned Command-and-Control world. In his standard work on “project-based work” J.Rodney Turner wrote about research in Australia in (if I remember well) the early 1990’s. In that research hundreds of projects were looked at that all finished on time and to budget. Five years later these projects were all, without exception, seen as failed. This is a very strong indication that the focus on time and cost is breaching the PRINCE2 Principle of Continuous Justification.

Edwards Deming and Goldratt

The man behind the Japanese quality movement, Dr.W.Edwards Deming also made quite clear that focus on cost/time, efficiency and standardization will only lead to higher cost because of a lack of quality; a breach of the Principle that focusses on Products (and their quality!). Also Eli Goldratt (The Goal) presented this view. Local efficiency leads to ineffectiveness. Eli Goldratt introduced the term “Cost World” for this old-fashioned ineffective thinking.
In the same direction: we all know that the majority of cost (60-80%, a conservative estimate) of a product is spent during maintenance and support. So why would anyone want to increase this percentage by lack of quality during a project by focusing on time and cost? Basically another Principle is breached: learning from experience.

Then there is a reference to Henry Ford. Ford strongly believed in Scientific Management by Frederick Taylor. This philosophy was strongly based on distrust; laborers were not to be trusted. They were lazy and could not be motivated. So Taylor and Ford created a soul destroying system where people were not allowed to think and processes were completely standardized. Remember Charlie Chaplin’s Modern Times? Even products were completely standardized. Never mind quality, never mind the customer’s opinion: "You can have any color as long as it's black." Ford and Taylor were only interested in efficiency: time and cost. What is one of the Agile principles? Time and cost are fixed.

So my view? Agile is not agile at all. It is based on old fashioned inflexible, low quality management as proposed by Taylor and Ford. Ford at one point found out it just did not work. His customers turned to more flexible and higher quality suppliers. The same will happen with the current Agile thinking. Hopefully it will be replaced by “quality first” thinking, the real agile approach that made companies such as Toyota so successful.

I always presented PRINCE2 as a very agile way of thinking. With the tolerances, the management stages and the continuous justification, high level/detailed planning and re-planning, for me there is no other way than an agile approach. But real agile; not this time-boxing/low-quality, “short-term cheap / long-term-expensive approach”.

Conclusion: the focus on time and cost is contra productive. And what does (PRINCE2) Agile propose? “Be on time and hit deadlines”. Just silly; so much against PRINCE2; so much against really agile.

An addition.

This blog provoked a reaction on LinkedIn.

What Agile Evangelists usually ignore or don't want to see, is that under the Agile regime there are far more frequent deliveries (iterations, releases) but that it takes far longer until it finally works. This is the conclusion that I hear every time I discuss Agile with someone from the user side. Very much in line with the attitude of Ford, the IT-industry promotes Agile from a self-centred point of view, with a disregard for users and quality.

Add to this the term Technical Debt, a term often used in an Agile approach...