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, June 19, 2003
Critical Chain-based Project Management and (not or) XP/Agile Development -- Yesterday, Clarke Ching, a participant on the NewGrange PM discussion list posted a question that Kent Beck posed on a lean development discussion group in which I don't participate. My response via NewGrange seemed worthy of repeat here:
[ching] Kent Beck asked the following question on the lean
[ching] development yahoo group:
[beck] "Here's my question about critical chain--they work
[beck] very hard to time sequence a fixed set of tasks...
Tasks, in the CCPM paradigm, are about creating deliverables with a particular resource (or set of resources working for a solid period of time cheek to jowl with more interaction than one would want to try track in a plan). If one considers an XP/Agile "story" as a deliverable, and the "pair" or "team" as the resource, there is very little conflict between XP/Agile and Critical Chain in terms of definition of task or effort. The details of what the "resource" does during the time that defines the "task" getting to the "deliverable" is not of concern in the CCPM paradigm -- at least as far as "managing the project" is concerned -- only a rolling estimation of time to when that deliverable will be available to the customer or to the next story/deliverable/task/team that requires it.
CCPM doesn't work hard to "time sequence" tasks. We work hard to understand the relationship of potential dependencies of deliverables between tasks in order to assure that missing dependencies don't threaten the ability to keep promises of desired functionality within a given timeframe. If the development of deliverable B requires deliverable A to start working on it, then there is a predecessor-successor relationship between A and B. If there are no handoff dependencies, then it is possible to work on the two in parallel, if sufficient resources/teams/pairs are available to do so. If the two are not both needed to create some larger chunk of value, then they are separate projects.
My understanding is that XP tends to estimate how much work will be done in a short time frame. CC Buffer Management, during execution, uses estimates of how long it will take to do a finite, understood chunk of active work. Future tasks in CCPM, roughed out to appropriate levels of detail (sometimes known, sometimes quite fuzzy) -- to make initial promises to the owner/sponsor/customer/organization are always subject to change based on learnings along the way, with assessments of changes in the consumption or replenishment of buffer allocated to protect the project promise.
[beck] ...using a fixed set of resources...
Promises need to be based on the availability of skills in the time period involved. In the short term, resource/skill pools are fixed for most organizations. If there is an infinite source of skill available (and applicable) in the short run, then a schedule/promise associated with delivering a set of deliverables can take that into account. The promise is then based on the "fixed" expectation of infinite resource. If not, then yes, resources, aka skills, are fixed at some finite capacity.
While I read a lot about XP/Agile work being done based on people "signing up" for stories on index cards tacked to the wall, the recommended CCPM approach to assignment of "people" to tasks is a similar "JIT" approach. As tasks cross a relatively short-term horizon in which their predecessors will allow them to start, available people with the necessary resource skills can be given a heads up that a task that can use their involvement is coming up. In this way, CCPM provides a means of using resources that are not necessarily dedicated (or fixed, per se) to particular projects, and therefore provides the basis for managing not only single projects but pipelines of multiple projects that can utilize a shared pool of resources.
[beck] with tough resource mapping constraints.
If one understands that resources are skills and not necessarily the bodies that contain them, yes, the mapping of needed skills to the work associated with building a deliverable could be considered "tough." They need to be to assure that you have the skills necessary to do the work you anticipate needing to create the deliverable.
[beck] In XP, we work very hard not to have tough resource
[beck] mapping constraints (pairing, tests, collective
[beck] ownership) and not to have a fixed set of tasks (to
[beck] enable business discovery during development).
As mentioned previously, a set of dependent tasks anticipated for the effort is required to make promises about functionality in a longer time frame. The flexible nature of a buffered CC schedule allows for the rational use of rough, uncertain, fuzzy "tasks" where appropriate (often out in the future), that can be revised or refined as discovery or learning takes place in the earlier going, with resulting impacts on project buffers and therefore a quantifiable and manageable impact on the initial promise.
[beck] What does critical chain have left to say?"
The Critical Chain scheduling and monitoring processes are appropriately applied at the "project" level -- in an Agile/XP context at the level of the "release plan" -- which is how it was used by Segway, according to the Cutter Consortium article on the development project of their scooter. It provides a means of making rational promises for efforts that require sets of deliverables that must work together or that depend on one another. It also provides a means to protect that promise as the initial expectations collide with reality -- without having to go into crisis mode at every little blip. Buffers are great absorbers of additional iterations that might be needed to assure optimum quality of delivered value.
I still have a hard time understanding where promise-making (other than in the promises of short-term tasks/deliverables, or in the promise to deliver something larger as soon as possible) comes into play in the Agile/XP approach.
[ching] Could you clarify something for me: Are there
[ching] variables - time, environment, perhaps - where you
[ching] think CCPM and (say) XP might be more appropriate?
If the project is about individual, independent, chunks of value, and therefore about single unconnected stories/tasks/deliverables, then CCPM might be seen as overkill for managing individual effort. Once dependencies between tasks, requiring "release planning" comes into play, CCPM provides an excellent framework for making and keeping project promises, both supporting and utilizing the XP/Agile task/story/deliverable methods in what we in CCPM call "relay-race" and "single-tasking" behaviors.
That said, even in cases in which we are talking about "single task projects," there still remains the necessity to manage the portfolio and pipeline of multiple projects in which the individual efforts exist. The use of CCPM-based multi-project management comes into play as a superior approach to prioritizing the attention of people and skills to the maximum benefit of the larger organization.
posted by Frank - Permanent Link -