Software Best Practices

Technically, no you cannot apply CCPM on an agile practice. CCPM is built on an activity network that you add feeder and project buffers. The underlying assumption is you can define all the work and their dependencies. This is counter to the underlying agile assumption that the end state keeps changing.

Recently agile proponents have been starting to add agile release planning practices to their projects. This is in a response to customers who need visibility into large initiatives or those organizations that cannot absorb change every sprint (e.g. every 3rd sprint goes to production). In theses case, some of the key CCPM principles and concepts can and should apply. Specifically:

• Identify your bottlenecks. As you build an agile release plan, you need to know and base your decisions around your bottlenecks. For example, if your Product Owners and SMEs cannot resolve issues around a business process, you cannot include it in a sprint backlog even if it is the highest value item.
• Eliminate buffers from task estimates. Agile practices already do this.
• Use Feeder and Project Buffers. Teams often add a stabilization sprint in cases where there are multiple sprints per release. This is a form of project buffer. I know of other teams who schedule the demo a few days before the end of the sprint. This is a form of feeder buffer. I've also seen a team build a release roadmap that intentionally undersized every 3rd sprint (e.g. a catch-up sprint). This allowed them to absorb changes without changing the external stakeholder's overall expectations.

 To summarize, the techniques used on CCPM projects do not work on agile; but the CCPM concepts lead to a better release plan.

This is about where we got to in a conversation with one of leading CCPM vendors.  I like to keep iteration cycles at 2-3 weeks and I also like to keep a regular cycle (ie. I've seen significant benefit at keeping to a regular schedule of a 2 or 3 week iteration/sprint).  With that in mind, it doesn't make sense to define a chain for the iteration with a buffer which would make the iterations variable in duration. 

I am entertaining the thought of some kind of a project buffer.  By the nature of our business (R&D), it can be difficult to predict how long the overall project will take to meet the objectives of our internal customer.  Something like COCOMO 2 can help but it is a top down (parametric) estimating technique, so there is more variability.  We can define some overall project buffer and consume (or give back) at the end of each iteration in evaluating how much was done (or, more likely, what new learnings created more stories/backlog).

So I'm thinking the value of CCPM may come in our ability to communicate when we think we'll meet the project objectives (and when those developers can be assigned work from a different project).