"Déjà vu" all over again, or why PMI/PMBOK are dangerous for the agile movement

There are significantly different sets of beliefs between what I call Old-Skool project management (embodied by PMBOK) and what is emerging as Agile project management for Software Development.

Old-skool project management is based on values and scientific breakthroughs that are over 100 years old.

• Scientific management (Frederick Taylor, circa 1911)
  
• Cost based management (optimizing costs vs optimizing the whole system)
  
• Deterministic process control
  
• Don’t trust the people, give them a process that cannot fail!
  

Looking at those values to build today’s development processes is: useful, but not enough.

Just like in architecture we can learn a lot from the old pyramids, but that is not enough to build today’s skyscrapers.

Agile project management tries to incorporate breakthroughs that have happened over the last 100 years and give a fundamentally new perspective to work and work management. Some of the breakthroughs are:

• The effects on productivity of empowered and self-managing teams
  
• Empirical process control (inspect and adapt). Software development project environments are complex. The customer may not know enough about the problem domain, the developers may not understand the problem correctly, the problem domain may be very difficult and multi-dimensional, etc. Things are changing all the time. You need a process that adapts to that change.
  
• Complexity Science: how large complex systems behave and the effect of trying to model their behavior on predictability (or lack thereof).
  
• Shewart/Deming’s Cycle of Plan-Do-Study-Act
  
• Lean Manufacturing
  
• Toyota production system / Toyota product development system
  
• Knowledge work how it is different from the work we previously understood
  
• Deming’s work on the importance of quality in costs, productivity and profitability
  

The important thing to remember is that the new way of looking at project management incorporates many years of evolution. The new project manager is faced with a lot more science and background today than 100 years ago. Our work must take that into account.

Using a paradigm that is rooted in the old principles of work management is not just bad, it's wrong. It can still be useful, but it is not adjusted to our current reality.

To quote Don Reinertsen in his latest book[1]:

Today's orthodoxy has institutionalized a set of internally consistent but dysfunctional beliefs. This has created a tightly interlocking and self-reinforcing system, a system from which it is very difficult to break free. Even when we change one piece, the other pieces hold us back by blocking the benefits of our change. When our change fails to produce benefits, we revert to our old approaches.

Without challenging and removing these self-reinforcing beliefs we are doomed to stay in the same place. And this is why our recent look at PMBOK and PMI in the Agile community is worrying. Not that PMBOK is wrong in itself (read that quote again), but that it represents a set of beliefs that is fundamentally contrary to what is behind the Agile movement.

I will continue this series of posts to look at specific parts of the PMBOK, but keep in mind that what I'm trying to do here is to expose things that are fundamentally wrong with PMI/PMBOK, not just suggesting minor adjustments.

[1] The Principles of Product Development Flow, Donald G. Reinertsen

Photo credit: Shyald @ Flickr