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 
various 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.
Planning
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.
Release/iteration
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.
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.