CCPM and Agile / Kanban
How similar are Critical Chain Project Management (CCPM) and Agile management methodologies? The Critical Chain mailing list has taken up the topic over the last several weeks, looking at similarities and differences between CCPM and Agile. We've also covered similarities to manufacturing approaches like TOC's drum-buffer-rope and kanban from Lean. And additional ideas came up, associated with David Anderson and his Kanban approach that is a mixture of several of these approaches. (I wrote a review of Kanban a few weeks ago.) I mentioned the discussion to David and he asked me to summarize. Rather than hiding the summary in an email, I figured I would do that here.
Since this is a CCPM-focused discussion list, much of the conversation has talked about how things are done in CCPM and the (perceived) differences with the other methodologies. In my mind, a lot of the discussion has been about gaining understanding of the terminology and operational differences (and similarities).
One of the big terminology issues has to do with the term "kanban," since Anderson's book is called Kanban but does things differently than Lean manufacturing's use of kanban cards. While Lean manufacturing uses kanban cards as a signaling mechanism to the previous operation that it needs to produce a new batch (ideally batch size of one), the Kanban approach is a visual system that uses cards to indicate status and location of work within a given work stream. The cards are an explicit representation of the work-in-process (WIP) in the system. This visual representation (on a wall showing the workflow and WIP limits) is an important aspect of Kanban. CCPM itself doesn't have a visual control mechanisms, but many implementations use the reports from their CCPM software to produce reports and hold meetings with the information provided by the various buffer status reports.
I am particularly interested in how one could use the CCPM and Kanban approaches together. In my reading so far, Kanban makes a lot of sense for groups that have a common flow of work together. The examples in Anderson's book were often of software maintenance, but I could also see this at work in an analytical chemistry lab or an engineering design group. Essentially, any group has incoming work that needs to be completed and many people involved in making it happen. While this might be handled within the larger PM environment, maybe that is too high-level. In that case a Kanban approach would be great for helping these groups get work flowing through their local system. I have seen examples where this type of workgroup has a large backlogs of work and no satisfactory mechanism to prioritize and complete the work, other than who-shouts-loudest. CCPM definitely helps them, but there are significant non-project elements to their work, and the particular implementations have stayed out of the "details" of their workflow.
Are Kanban or Agile approaches appropriate for all types of projects? Critical Chain has shown its value many times in large, single projects and in areas where the same type of project is repeated, and in multi-project environments. Several people suggested that Big Projects (building an aircraft or a house) don't fit very well within the nature of Agile or Kanban. But then many Big Projects have elements that are repeated or that use highly repeatable processes where these approaches could be embedded into the overall project. Another element of this discussion looked at the type of workflows: if there are significantly different work flows, then a Kanban-like visual control system might be difficult to design. However, I suspect there is more to reveal down that direction of the discussion.
The discussions followed many other trails as well. We got into how the approaches create pull, WIP limits, and batch size reduction - all end results of these methodologies. We talked about how buffers are used in the various approaches. And about how the different approaches deal with situations where something appears to be stuck and some form of expediting is required.
One of the more active and curious participants in the discussion has been Larry Leach, himself the author of books, such as Lean Project Management. He is always looking to connect the elements of his work and his vast reading together, and he was active in taking the discussion in several directions.
Another participant, David Peterson, pointed to his useful description of Kanban, which helped the discussion. It was nice to have David's input, as he has more direct experience with Agile and Kanban in software environments. Many of the other participants were looking at the topic from the interested-but-not-experience viewpoint.
I'm sure I have missed some things, given the extent of the discussions. I hope this helps anyone who is curious.
[Photo: "Comparing and Contrasting" by vanhookc]
Previous entry: Information #jail entry and exit