A friend of my mine was asking me about Agile this weekend and he threw me a bit with a question about Critical Path Analysis. By coincidence, I note that another blogger has also covered this recently at
http://scrumblog.scrumpractitioner.com/2008/04/28/tracking-critical-path-with-scrum/trackback/. I thought I would add my take on this also.
First off, do we actually need critical path analysis (see
here for a quick Wikipedia explanation of the technique)? In Scrum we assume that we do not know everything about the project we are working on. CPA assumes that we do. CPA is used for scheduling a project. With Scrum we use the Product Backlog and just get on with it!
From the point of view of scaling, my client HR SoftCo takes a Scrum Of Scrums approach. This means that any problems that can be solved other teams are escalated through to the Scrum Of Scrums where a solution is arranged. The key difference between CPA and Scrum is therefore the difference between scientific and empirical management. With CPA we try to prove that there is a known set of activities and an ideal solution that can be determined at the outset, whereas with Scrum we believe that there is not enough information at the outset to determine an ideal solution.
Since we do not have fixed estimates in Scrum until a feature from the Product Backlog is allocated to a Sprint, the process of CPA becomes increasingly expensive to maintain as the critical path is always in flux. The cost of maintaining a critical path may be greater than the value of having it. It is also worth considering the value of the critical path in the light of it being in a state of continual change.
There may still be a place for CPA on large projects or programmes, however. Where several teams are involved a very broad and low-granularity critical path may be useful for working out when to bring on new resources / removed unneeded resources. The path would have to be very simple in order to be resilient to the changing situation.
In conclusion, I think that CPA has no place within a single Scrum team, but may be useful at a very high level for large projects with lots of Scrum teams.