This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Thursday, December 11, 2003
Agile/CCPM - Non-Meaningful Distinctions -- A recent thread in the TOCExperts YahooGroup has touched on the subject of SCRUM, one of the family of Agile approaches to [software development] projects. Being a Theory of Constraints oriented discussion group, it was not to be unexpected that at some point in the conversation, a "comparison" with Critical Chain-based Project Management (CCPM) would pop up. Clarke Ching, a frequent and knowledgeable member of TOCExperts, offered an excellent summary of SCRUM for the non-practitioner, but within it, he offers a few bullets on how SCRUM differs from CCPM that are worth some questioning comment. The first "difference" offered is that...
CC aims to get the project finished as quickly and reliably as possible. Scrum aims to get working functionality delivered as quickly as possible.
This is, in my opinion, a non-meaningful distinction, as the basis of the difference is in the comparison of "project" and "working functionality." In a CCPM-managed project, there is nothing to say that the objective deliverables can't be pieces of "working functionality." There is nothing to say that individual pieces of "working functionality," delivered via SCRUM practices, can't be assessed vis-a-vis expectations of cost and schedule via CCPM's buffer management, either as individual sub-projects, or as deliverables diverging from the mainline critical chain of the overall project. The management of the effort is related to the second offered difference...
CC buffers with time. Scrum buffers with functionality.
Now I've been known to utter similar comments about buffering with time versus buffering with scope, but reviewing some recent descriptions of "burn-down" charts common to agile environments (and perhaps viewing the recent PBS NOVA episodes on string theory), I've come to a view of scope and time as sufficiently intertwined to be only one of perspective. Like the idea of space-time, drawing too fine a distinction between the components of scope-time is a distraction at best. Too much scope left (for the time we wanted to deliver it it) and not enough time left (to complete the work we would like to) are the same thing. Any decisions about changes in the work content to recover our initial promises/targets or the deliverables that we finally produce in either approach immediately get into the question of time of work remaining (and vice versa).
At the practical, less metaphysical, level, the content of SCRUM meetings are nothing more than the equivalent of the content of CCPM's daily buffer management reviews of single projects. "Burn-down" charts, used to assess what is left in SCRUM and other Agile project environments can map directly to CCPM buffer consumption analyses. Both, with their forward-looking view, are superior to the backward focus on supposedly immutable baselines or completed work as the source of "earned value" in other approaches to projects.
The third difference is offered as...
CC says "Don't put the safety in the task; put it in the project." Scrum says "Don't try and figure it all out up front because you can't. Things will change too much as you go. Instead, build working software quickly, inspect and adapt."
Again, I don't see the "difference." I almost saw putting these two together as a non sequitor, but then there might be some connection, and again, more similarity than difference. SCRUM and other Agile approaches use plans for their efforts. They're just not detailed in a way that locks them into a calendar or to artificial dependencies to make promises, mapping them instead to a set of time-boxed sequential iterations or sprints. CCPM also frees the interim activities of a project from the calendar by removing the idea of task level safety, commitment, and due-dates.
As in most things, when there are two common sense approaches to a particular issues, there is often more in common than there is different.