The challenge to the Agile community: can't we do better than PMBOK?

Another Knowledge Area in the PMBOK is Human Resource Management. The very name of the knowledge area already gives away the values behind it. It should not say “resource management”, it should say People Management!

The old-skool project management is very much based on the values of Scientific Management and Hierarchical organizations that have permeated our society for hundreds of years. Surely there is a lot of useful things to learn from this, useful things for sure, but not enough.
In order to be able to better handle the unpredictable situations we will regularly face, we need to be able to self-organize to better respond to the challenges presented.

What is self-organization? A technique to enable a faster way for a team to answer any problems that cross their path. Before, when following the command-and-control values a team would have to stop and wait for the boss to leave a meeting and finally ask the boss what to do next. Today, teams are required to self-organize, find a solution or several solutions, experiment and come-up with the final result. When the development iteration ends, the customer will tell the team whether the solution is good enough or not.

Not allowing a team to self-organize turns the old-skool decision makers into bottlenecks that delay the team and potentially the whole project.
Self-organization, however is not easy, you cannot order or wish it into reality. You have to work hard to enable that to happen. Scrum is a process framework that already has some of the needed ingredients for self-organization to happen.

Through the setting of clear goals and it's governance framework, Scrum allows the team to be left alone during an iteration (after having agreed to a set of clear goals). In the Sprint Review, the customer/Product Owner will come together with the team and evaluate what was delivered. This evaluation, in turn, is input to the planning of the next Sprint

So, the message of this series of posts is embrace change.
However, even changing some aspects of the project management body of knowledge (PMBOK) is useful, it is not enough!

A mind shift is needed;. So many new concepts are in play that we must start thinking about Software project management in a completely different way.

We need to change the culture in our companies/organizations. Companies as a whole need to change.

The challenge that is presented to the Agile community (and to the PMI Agile community by extension) is: "how do we benefit from the breakthroughs that have enabled Agile SW development to emerge"?

As a person that has tried the "change PMBOK" approach, my answer is that we need to forget about PMBOK and start afresh from a different set of principles to those that were at the origin of PMBOK.

The recent field of Product Development with authors such as James Morgan, Donald G. Reinertsen and others, together with the people writing about software development present a sufficiently convincing and engaging view to the software development system. Those views demand a serious inspection of PMI/PMBOK approaches. The Agile community must take up that task and come up with something credible. Just embracing PMI's Agile community is not enough. The world has changed enough to warrant a different approach.

"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

PMI and the meta-planning process, or why software development planning is different

In the previous post I said I'd talk about Project Integration Management. Of that knowledge area from the PMBOK, I'll focus on one specific Project Management Process within the Project Integration Management (this is how PMBOK calls the different components for each Knowledge Area).The process I'll focus on is "Develop Project Management Plan".

There's an important distinction between what PMBOK suggests and what I've seen in the field (in software development organizations). The PMBOK talks about the project manager having to build a project "management" plan. Note the difference: not a project plan, but a project "management" plan.

The reason for that is, according to PMBOK: This process is needed

for defining, preparing, integrating and coordinating all subsidiary plans into a project management plan. The project management plan becomes the primary source of information for how the project will be planned, executed, monitored and controlled, and closed.[1]

In plain English this means that before you start the project you need a "meta-plan", i.e. a plan on how you plan to plan & manage the project (read that sentence again, it makes sense...)

In many (but not all) software organizations this particular process makes no sense. Why? Because it is very likely that you are involved in developing the next dot-version or major version of an existing software product/service. This is a major difference to what PMBOK and the PMI certification/approach is about.

In software, a lot of what we do is very much akin to what PMBOK calls "operations", i.e., a time-limited development effort within a context/organization that is pre-existing and has processes in place to deal with this (ongoing work vs. temporary and unique work). For the majority of the software organizations and projects out there this process is simply not useful.

It is important, of course, to be aware of this "meta-plan" or processes. For that reason alone it would be beneficial for many to read books like Alistair Cockburn's Agile Software Development or Jim Highsmith's Agile Project Management or even PMBOK (less entertaining as it may be).

Being aware of this "meta-plan" or process is very useful, but not enough. In other words software project managers can still benefit from what PMBOK describes: PMBOK is useful, but not enough for software development endeavors. This will be, as we shall see, a running theme in this series of posts.

Tomorrow we will talk about the Project Scope Management Knowledge Area and why the Scope Planning process in PMBOK is out of synch with today's (agile) methods for developing products in a software organization.

[1] PMBOK Guide, 3rd edition, 2004

A message to PMI: let's start a much needed dialogue. First post

Why PMI style project management is different and why should we care? Continues...

Given the brouha about my last post, I thought I'd give my self some posts to clarify where I think the big differences are between Agile project management and the PMI-style project management (this last one I will affectionately call old-skool, because I too was once an old-skool project manager).

I will try to be fair and balanced, but my bias (borne out of experience) is towards Agile project management, so be warned. This series will not be an account of how PMI-style (or old-skool) project management is good, which it no doubt has been, but is more likely that this series will be seen as an account of the old-skool project managment's Swan Song.

The odissey starts

When thinking about this series of posts (of which this is the first), and how to convey the message I have in the best possible way I could not come with a better way then to just start by stating it up-front:

Embrace change!

If there’s one thing that I would like you to take with you after this series of posts is this: The world has changed, and project management has changed, and will continue to change with it. You should embrace that change.

There are many reasons to embrace this change in project management.

I give you only 3:

1. Your are more likely to succeed if you change
   
2. And it is more Fun to succeed.
   And if the previous 2 reasons did not convince you here’s one more:
   
3. If you don’t change others will, and soon you will be out of business
   

So, in this series of posts I’ll try to cover some things of what I think any project manager (PMI or not) needs to know in this new world of project management for software projects. I’ll look at the Project Management Body of Knowledge (PMBOK) from Project Management Institute – which is an ANSI standard in the US and I’ll try to tell you what new you need to know regarding the 9 areas of knowledge in the PMBOK.

The first area we will focus on one is Project integration management (or project planning for those that are not familiar with PMBOK): This area includes Project plan development, project plan execution and integrated change control (and some other items).

Check back tomorrow for my comment on how an Agile project manager should look at Project Integration Management.

Image credit: Louisville Joe @ Flickr

PMI vs. Agile, what is different, and why should we care

The PMI people don't seem to stop trying to "guess" what Agile is. Guessing is the right term, because anyone with more than a few hours experience in Agile software development can see their cluelessness from afar!

Take this article by Lynda Bourne DMP, PMP (no, I'm not making those TLA's up, she uses them). She says that Agile is different from waterfall because:

• The need for robust change management and configuration management to track the evolution of the Agile project
  
• The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Someone that says that in Agile project management you need "robust change management and configuration management" probably does not even understand what those are, let alone Agile. Hear me out: Change Management is not needed in Agile, Agile *IS* change management. Take Scrum for example, the whole idea with Scrum is to provide a framework for accepting and managing changes. Scrum *IS* change management. To say that Agile project management "needs" strong change management is to miss one of the most elementary points of Agile Software Development.

Then comes the killer: we Agile project managers (supposedly) need to focus on "developing the correct strategy and architecture at the beginning of the Agile project", missing this - Lynda writes - will lead to failure. Only one word: WTF? C'mon Lynda, that is probably the largest mis-conception of Agile Project Management that I've seen in my (admittedly) short life!

There are thousands of posts about why Agile people focus on "growing" architectures rather than "getting them right up-front" (aka BDUF). Please read up, just google for Agile Architecture and you will find many articles that explain how in Agile we look at Architecture development (here's an example link).

There seems to be a lot of discussion happening in the PMI circles about Agile, but PMI people need to understand that the practices they've developed for building, acquiring companies, etc. don't all apply to software. PMI people should first learn about software and then Agile. Trying to bypass software and going straight for an Agile take-over will only get us (the software industry) another 10-years back in time and lose so much of the evolution we gained with the Agile movement.