More CBPM & Agile Thoughts

race-car.jpgWe had some good discussions in LinkedIn’s “Project Acceleration through Commitment-Based Project Management“group with respect to my prior blog. One individual indicated that CBPM should be viewed as another Agile framework, just like Scrum. That idea reinforced my thoughts about CBPM and the fact that it fits properly within the Agile philosophy.

CBPM focuses on getting deliverables done with as few “drag” (non-value or low-value) activities as needed. The owners determine how to deliver on their commitments, including making sure that any dependencies on other deliverables are understood and taken into account. Management oversight is minimal.

The inspect aspect of Agile is addressed via the discussions that owners and customers have on the deliverables and the final say that the customer(s) has/have on whether the deliverable is done or not done. This feature, the need for owners and customers to discuss the scope and status of deliverables, is a variation of the Agile inspect process at the end of an iteration.

Iteration-wise, CBPM is not fixated in any length of the iterations or cycles. The goal is to complete deliverables of value as quickly as possible. Due to its origins in the hardware business, there’s less emphasis in wrapping up a set of deliverables into a release or sprint, although that is very viable.

CBPM is an Agile framework that has some key capabilities (i.e., support for non-software projects) that other Agile frameworks may not. This does not mean that it is not usable in software efforts. As a matter of fact, it can easily be applied to software efforts, even to those run under the waterfall method (gnashing of teeth here! đŸ˜‰

If Intel can plan and deliver some of the most complex products in the world using CBPM, almost any project can use it.

CBPM and Agile — a brief comparison

Recently I’ve become re-acquainted with Agile methodologies. I say “re-acquainted” because in the 1990s, when I was running the Intel Inside (R) Program system development we sort of fell into now what would be called Agile. We time-boxed, had rapid iterations/releases, had customers working with us at all times, provided value to our customers as fast as possible.

A friend of mine indicated that there might be an opportunity to help as an Agile coach so I dug into it, attending Agile Palooza on 8/14 in Charlotte, NC and reviewing the numerous books that I have on the subject. It struck me that there are a number of similarities and some differences between the two approaches.

Deliverables and Features

Readers familiar with CBPM (Commitment-Based Project Management) as described by Timm Esque in No Surprises Project Management and presented in nosurprises.jpgvarious workshops, blogs, etc. know that CBPM focuses on deliverables, items of value to a user or customer, whether it is the ultimate customer or an intermediate one. Tasks that get us there are ignored as far as the overall planning and tracking is concerned. The individual is responsible for figuring out what tasks need to be executed to complete the deliverable.

Agile focuses on features, which I would classify as a synonym for a deliverable. There’s a difference, though, in that these features are for the ultimate customer. Agile seems not to address the intermediate deliverables directly. They, instead, are handled as part of the development process.


Agile does just enough planning to figure out the next release and, more specifically, the next iteration or sprint. There’s an overall vision of where the project is going and there is some longer term planning but it’s pretty fuzzy.

Similarly, CBPM focuses on detailed (at the deliverables level) planning for the next 6-8 weeks, the commitment horizon. It does look further down but the plan dates are estimates, not commitments.


Agile groups features into iterations that, in turn, are grouped into releases. At any one time the software developed by an Agile team is production-worthy as of the last iteration that was completed (ideally, every day as the constant recompilation and testing of the code ensures that the code works. If it doesn’t, it has to be fixed before any additional work takes place).

CBPM does not necessarily group deliverables into releases. This is an option that the team may choose to do. However, with its focus on weekly measuring performance in terms of items completed as per the commitment, the weekly results could be viewed as a release. However, there is no logic behind this grouping so this comparison is weak.

Burn-down/up chart and PAC

Agile uses a burn-down (or burn-up chart) to track the completion of features against the plan. Similarly, CBPM tracks performance against a committed set of deliverables. While there are small differences in the details, both charts reflect the same information: how well is the team performing against the plan.

Application Areas

Agile has been applied mostly to software efforts. There have been some discussions  on its application in other areas (see Jim Highsmith’s Agile Project Management for a very good discussion) but, overall, it’s application is mostly in software projects.agileprojectmanagement.jpg

CBPM, on the other hand, started with hardware projects (designing Intel’s semiconductors, specifically chip sets, the chips that support the microprocessor) and has been applied to construction, manufacturing, aerospace, education, software, and other projects.

Preliminary Conclusion

There are many similarities between the two approaches and some differences. It is possible that both may benefit from each other so I’ll keep investigating to determine where best to adapt practices from one approach to the other approach.