PMBOK and Agile Article

    On AgileLeadership forum there is a reference to an article by Michele Slinger describing the relationship between PMBOK and Agile titled Relating PMBOK to Agile Practices. This  fine set of articles suggest there are similarity's  between PMBOK processes and agile processes. This may be the case, but some care needs to be taken before too far down the road. This is because there is sometimes a lack of understanding of the subtleties of project management processes in the agile community. As well PMBOK is probably no the best place to go looking for project management processes for software projects.
    First a word about PMBOK. It has a nice table of contents and some content that is useful. A much better PMBOK is the DoD PMBOK which took the TOC of PMBOK and rewrote most sections to be "executable" in terms of actual project management practices.
    I started reading Part 1 about the PMBOK process areas mapped to Agile practices. The PMBOK process groups are reviewed and Jim Highsmith's Agile Project Management (APM) is compared. The orginal article did not have the definitions of the PMBOK items. Which are added before for some clarity:

• Initiating (defines and authorizes the project or a project phase) → Envisioning
• Planning (defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project was undertaken to address) → Speculating
• Executing (integrates people and other resources to carry out the project management plan for the project) → Exploring
• Monitoring and Controlling (Regularly measures and
  monitors progress to identify variances from the project management plan so
  that corrective action can be taken when necessary to meet project objectives) → Adapting
• Closing (Formalizes acceptance of the product, service or
  result and brings the project or a project phase to an orderly end) → Closing

These "words" are mapped, but its not clear the underlying process are maped of each other. Nor are the Knowledge Areas of PMBOK mapped, which relates to the processes and the knowledge needed to deliver the process. More on that later. And even more important the Process Groups in PMBOK contain processes (hence the group) that have specific descriptions. The DoD version has even more detailed descriptions. No such details are found in the Agile Process areas. So there's a bit of "apples and oranges" here, but for now let's keep going.
    Getting to Part 2 turned up the first gap for me. Figure 1 shows a comparison between Agile and the old stalking horse - "Waterfall." The comparison is:

• Waterfall: The Plan creates the cost and schedule estimates
• Agile: The vision creates the feature estimates

So one step at a time:

• Waterfall - it is certain the "Plan" creates the cost and schedule. Just as it should be. In fact most of our clients don't do this and get cost, schedule and planning all balled up. In the IMP/IMS processes used in government contracts larger that $20M, the "Plan" is the Integrated Master Plan. The Plan is the Strategy for successfully completing the project. Certainly the Plan is needed before he Schedule is developed. Without the Plan, the Schedule has no home for its activities.
• Agile - the vision creates the features. This makes good sense of course. Where else would the features come form. But where is the cost and schedule? With the set of features, how long will it take to produce them? How much will it cost in the end to get those features?

What really happens in the agile approach though is the "plan" becomes time boxed. The cost and schedule are fixed and the features deliverable fall out. This is a viable approach if several condition s exist:

• The team knows their capacity for work - how many features can be done by how many people in how much time?
• They know their breakage factor - for each of these features, how many make it into the final delivery?

The first question can be handled. The second one requires care in not letting features enter the project that will not exit the project. The "feature breakage" rate needs to be carefully tracked. This is really the "requirements churn" measure. This is no different in the traditional project management method.

Measuring and managing the requirements churn is critical  to the success of any project, no matter what the method.

    In the next paragraph (after Figure 1) Michele says "The PMBOK practices of scope definition, work breakdown structure (WBS) creation, and scope verification occur iteratively in agile." This is completely arbitrary of course. PMBOK makes no suggestion as to the order of work. Although in previous editions of PMBOK there were examples of Spiral, the current edition is devoid of any "time based" processes. This is were Agilest start to get out of their domain. Iterative and Incremental life cycyles are the bread and butter of the defense programs I work on.
    In a paragraph near the end of this Part Michele says: "The critical path is no longer identified." The problem is of course, there is no critical path in agile because it is a Time Boxed schedule. So in fact, every iteration is on the critical path, because there is no schedules slack. As well the critical path may not be needed for a self contained software development project. But for a multi-partner defense systems development the critical path is just that critical. Same for most every construction projects, manufacturing product project. I worked part of a Pharma plant built near my home in Niwot and we lived by the critical path every day. 100's of parallel activities were needed to get the plant built, equipment installed and operational on the promise date so drugs could flow to customers. This notion that the Critical Path is some how evil - is not only misguided, it is misinformed.
    The factual statement would be:

Each iteration IS the critical path. This is the definition of time boxing. It is also the technical definition of Critical Path. The Path that has Zero (0) total slack.

Ironic uh?
    The next Part (3) opens with a statement about risk management. This is something I know about, having defined, developed and deployed the programmatic risk management aspects of several multi-billion dollar programs. The suggestion is that agile makes risk management an intrinsic part of the project lifecycle. The same is true for any credible project no matter the method. Agile has no special claim to this. And likely doesn't have a deep understanding about programmatic risk the way NASA or defense programs do.
    The suggestion that agile doesn't have a risk management plan because it's built in is simply not evidenced by the materials found on an agile project. If I were to walk into a agile project and use the Software Program Managers Network (www.spmn.com) project Breathalyzer test and ask "tell me your top 10 or 5 risks," where would I find them? Written on cards stuck on the wall? That would be good. In the minds of the developers? That would be bad. Michele shows an example of cards, that's good.
    In the end the connections between PMBOK and Agile  appear to be similar. What Michele left out was the 9 Knowledge Areas of PMBOK

1. Integration Management
2. Scope Management
3. Time Management
4. Cost Management
5. Quality Management
6. Human Resource Management
7. Communications Management
8. Risk Management
9. Procurement Management

Each of thee has 3 to 8 sub-knowledge areas, each with some details about their application.
What does all the mean?
    It means that connecting agile with PMBOK will need some more work. More than just the process areas. Mike Dwyer and I tried this some time ago and then moved on to other things. It might be interesting to see how the agile project management practices - what ever they are - maybe Jim's - map to PMBOK. This might be useful for Michele and her clients and students. It might also be useful as a conversation starter about what really takes place during a project guided by PMBOK but in dire need of an "agile touch."