PMI vs Agile, the debate continues

Prompted by a comment by Murray on my first blog in this debate I wanted to expand some of the ideas that have not yet been explored.

Here are the key excerpts from Murray's comment:

PMBOK V4 is compatible with and supportive of Agile processes. Here are some relevant quotes from CHAPTER 2 − PROJECT LIFE CYCLE AND ORGANIZATION

"There is no single way to define the ideal structure for a project"

"it is up to the project manager and the project management team to determine the most appropriate method of carrying out the project"

"There are three basic types of phase-to-phase relationships:

• A sequential relationship (...)

• An overlapping relationship, where the phase starts prior to completion of the previous one (...)

• An iterative relationship, where only one phase is planned at any given time (...)

The PMBOK v4 is quite recent and I have to admit I'm not familiar with it.
However, PMBOK v3 completely omitted the discussion about phase-to-phase relationship in the way described above.

Another aspect that is seldom discussed is that in IT projects (specifically Software Products) we are very quickly distancing our methods from the project-concept. In companies where I've worked, projects no longer represent in any meaningful way how the company works.

Another caveat is that Linear-iterative projects (like RUP proposed) are significantly different from the Incremental-iterative project structure that Agile methods in general and Scrum specifically propose.

All in all, there are significant differences that warrant a very skeptic look at what PMBOK has to offer.

If you want to check some other views into why the "project" pattern is not necessarily useful for software product development take a look at this blog post by Ari, who has quite a long experience in product companies: "Focusing on projects ruins your business"

Photo credit: Dunechaser @ 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.

To all PMBOK, PMP and PMI people: you are missing 1 million points! Stop trying to explain something you don't understand!

The traditionalists are starting to be quite dangerous in the hostile "take over" of Agile and Scrum (Kanban can't be far behind).

In this post Glen tries to tell us that it is ok to call "project management" what we do in a Scrum (f. ex.) development effort.

Now, that would not be so serious if he did not go and quote the list of activities in the PMBOK and explain that because you are doing those, then you are (by syllogism, one supposes) doing Project Management. Well, it's not that simple as I try to explain in my comment to this article:

It's not that simple. One of the biggest changes that Agile brings to the development of software is that, for most (usually) so-called projects, Scrum (or other methods) change the approach to a more continuous work approach, i.e. the work is always ongoing, just the input (requirements) are being managed in a time frame (release).

So, to answer your question (are you doing project management in Scrum?), in many software projects you DON'T have project management, you have WORK management. Nevertheless you have all of the activities you list (except project initiation). Which also shows how useless the list is, because you always have those activities in any endeavour, project or not.

To sum it up. I think that PMBOK is a good read for newbies and people starting in WORK or PROJECT management, just like many other books are, but PMBOK is dangerous in one aspect: it singles out different aspects that should/must be part of every day work. Take the example of Risk management: in Scrum all activities in the process are risk management activities (planning, daily meeting, demo, retrospective...). If you follow PMBOK you get the idea that Risk Management is actually a different activity that may even include different actors/stakeholders. This is BS, pure and simple.

In my opinion PMBOK and the prevailing approaches to Project Management today are simply dangerous and destroy customer/shareholder value.

We need a new paradigm in project/work management and Scrum is a good start!

Project smells

Jason suggests that projects, in his experience, face similar problems (I'm assuming he is talking about all projects, including Agile projects).

What is your experience? What are the mistakes that happen all the time as Jason suggests?

In the waterfall world one of my favorites that happened all the time was: requirements change constantly. Can you imagine a world where requirements changes were a bad thing? I can't. I guess i've been exposed to Agile for too long (wink, wink).