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
Labels: agile, PMBOK, project, project management, projectmanagement
RSS link
8 Comments:
I think this quote is worth repeating in full "An iterative relationship, where only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, but it can reduce the ability to provide long term planning The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value. It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases."
By Murray Robinson, at October 08, 2009 1:12 PM
Here are some other statements in PMBOK 4 that are supportive of Agile development.
"Because of the potential for change, the project management plan is iterative and goes through progressive elaboration throughout the project’s life cycle." From Section 1.3 - What is Project Management
"This progressive detailing of the project management plan is often called “rolling wave planning,” indicating that planning and documentation are iterative and ongoing processes."
"Prototypes support the concept of progressive elaboration because they are used in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision."
By Murray Robinson, at October 08, 2009 1:32 PM
I really wonder about the idea of a "debate" between PMI and Agile ideas.
It sometimes sounds like folks think PMI is directing how companies decide to organize their projects and manage them.
Does the quote from v4 regarding an iterative approach make anyone think companies will now say, "Oh, OK, we can do this now 'cause PM I says so." Or does anyone think people using a traditional phased, sequential approach will stop because the PMIBoK now is explicit about being iterative?
I believe PMI, for the most part, simply reflects what most people in most companies think is the "right" way to do things based on large projects. This is just like most software standards which reflect what large, gov't and/or regulated projects believe is appropriate system "due diligence."
An agile standard, for example, will not cause people in this kind of project domain to suddenly turn to agile methods because a standard comes out about it. Those who want to do this will be able to point to a standard, but those who don't won't care such a standard exists.
The real issue for me is what folks advocate as the way to approach organizing work/projects.
To me, Agile ideas are trying to lead people to a new way of doing things (or remind them of a set of ideas that have existed over the years, but not used broadly). PMI, on the other hand, as I note above, is just reflecting and trying to appropriately describe existing belief and behavior in project organization. (This latter approach is, also, how standards work, codifying what people feel is established practice not trying to lead the way into new behavior.)
By Scott Duncan, at October 08, 2009 1:47 PM
@Scott
Good point Scott. Indeed PMI and other standard organizations are just trying to "describe" how some things are done. Not "define" how they should be done.
Here in lies one key conflict between PMI and the Agile community. In the Agile community many of us have been involved in trying to "define" how things should be in the future.
It is encouraging to see PMI taking up some of these concepts, but there are other fundamental conflicts between PMI ideas and Agile ideas.
I describe some of those here, here and here
By Unknown, at October 08, 2009 1:55 PM
I guess my point is that perhaps there should be no debate.
PMI is doing one thing and Agile is doing another.
PMI is describing what people feel is already accepted practice. While, at the moment, the Agile community is trying to promote what they feel should/could be an improvement on that practice, at least in many areas.
I say "at the moment" because it is clear there are camps in the Agile community with prescribed behaviors, too. It's just that these behaviors are not widely accepted or practiced in organizations, so the Agile ideas cannot be said to be describing existing, accepted practice in the same way PMI does.
But Agile ideas will inevitably head that way as more and more companies (and parts of companies) adopt an Agile approach. It's just the way large organizations work regardless of the idea.
Agile ideas "crossing the chasm" mean loss of (some) "control" over what organizations do with them, for good or bad. The Agile community's main difference from the PMI community is that the former resists codification since that's against the inspect & adapt idea. But codification will happen because there are going to be "Shu" interests that want, and believe they (and others in theirorganizations) need, it.
By Scott Duncan, at October 08, 2009 2:09 PM
@Scott
I guess we disagree about the need for a debate.
I see that PMI is taking some space in the Agile world (perhaps preparing an Agile Project Management certification?). Before that happens I believe that PMI itself must change. If that change does not happen it is the Software Industry as a whole that will suffer.
By Unknown, at October 08, 2009 2:20 PM
Well, certifications are another issue. I think a PMI run Agile Project Management certification would be rather meaningless if the PMIBoK did not have substantial Agile ideas described in it. What could one base a certification on if the body of knowledge did not include substantial material backing it up?
Now the APLN may have something to say about someone claiming to define what it means to manage projects in an Agile manner.
But the mere existence of the PMI(BoK) is not a cause for debate. I think the "work from within" approach that Jesse Fewell and others have been championing could prove more useful as time progresses.
Most of the opposition to Agile ideas around managing projects seems to come from individuals in organizations that are convinced traditional phased, sequential approaches with much up-front planning ansd documentation is the (only) responsible way to proceed.
I actually think, from what little I have read and seen of the newest PMIBoK wording, that PMI is not really taking that position. Now some of the PMI material may, as I said, be providing guidance on how to conduct a project using such due diligence expectations, but it is clear that isn't the only thing the PMIBoK says.
My main gripe with PMI is that they do not make their PMIBoK available (without a fee) to anyone, not just PMI members. The IEEE does this with the SWEBoK, for example. (I have the same gripe with ISO and IEEE standards, as well, especially since most of the money involved in creating them is paid by companies and governments. But that's another issue.)
By Scott Duncan, at October 08, 2009 2:56 PM
Great post! PMBOK V4 was thoroughly explained and because of this explanation, I guess there's no need for debate.
Both PMI and Agile are doing their own work well. There might be differences but they still help us in making our projects. Anyways, thanks for the post!
By Nathaniel @ project management certification, at November 11, 2010 7:31 AM
Post a Comment
<< Home