How Do Scrum and CCPM Compare?

November 14th, 2003 by Hal

This posting came from Clarke Ching, Scotland, writing in the TOC Experts Yahoo! Group on November 10. Clarke is a regular reader of this blog and the contributor of Project e-Tip 009: Eliminate Multi-Tasking to Speed Project Completion. Clarke is a smart guy who writes well. He graciously allowed me to reprint his posting. Thanks Clarke.

[Look for my comments throughout the text.]

A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM). Here's Clarke's reply.

Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations - between 1 and 12 weeks each.

The core conflict for software development projects (and most others I imagine) looks like this.

[This is a fine example of Goldratt's Evaporating Cloud]

    D - Allow change throughout project
  B - Build functionality required by customer
A - Have a successful software project
  C - Deliver on time and to budget
    D'- Agree scope up-front and don't allow change throughout project

Or this see this graphic provided by Clarke.

[Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D') to agree to the scope up-front and not allow changes throughout the project. (D) and (D') are in conflict and cannot coexist.]

In a traditional/waterfall environment "change control" is the mechanism used to do both D and D' poorly.

The agile approaches attack three assumptions:

Assumption CE1: We can prevent change if we spend enough time to ensure we get everything agreed and signed off up front. Agile/lean says that CE1 is just plain wrong (in all but the simplest environments). Therefore, E doesn't even give you C. Even if we get the requirements right up front, they will change, so if we don't change them as we go then while C (finish on time and budget) is satisfied, we won't satisfy B (customer gets what they need) so that A (the project) isn't successful.
Assumption CE2: It is many times more expensive (i.e. Boehm's cost of change curve) to change the further we get into the project. Agile/lean says that CE2 is wrong too. For instance XP (eXtreme Programming), a cousin of Scrum, suggests that the cost of change curve quickly becomes flat when using test-driven development and refactoring in a iterative/incremental approach.
Assumption CE3: The project only delivers value when it is finished. Agile/Lean says that you don't have to deliver everything at once to get value. Instead you can get value quite quickly by delivering small high-priority increments of the product. At the very least you gain value by discovering what's not working much, earlier.

[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.]

The key points of Scrum are:

A product owner manages a product backlog.: This is a list of high-level requirements/features - e.g. user can register, user can login, user can add items to a shopping cart, user can search for books, etc - that has been prioritized by the product owner. It will also include "technical things" - e.g. install server, upgrade source management system - added to it if requested by the developers and agreed by the owner.
Every 30 days a new "sprint" starts.: Each sprint is a 30-day iteration where the development team picks a set of features from the product backlog that they estimate they can "deliver" within the next 30 calendar days. They then work on that sprint for the next 30 days.
During this time no changes can be made to the sprint unless suggested by the developers.
"Delivered" means that the feature could potentially, although not necessarily, be shipped or implemented.: It's fully coded and tested, the help is prepared, it's not going to break when the users get hold of it.
Each scrum team is self-managing with guidance from the "Scrum master".: Initially the team will struggle with self-management but, apparently, they learn quickly. Each day a 15 minute meeting is held where each person answers 3 questions - what did I do yesterday?, what will I do today? And what obstacles are holding me up? It is the Scrum master's job to clear the obstacles.
The theory behind scrum says that complex processes, such as software development, change too much and are too difficult to manage.: They need to be managed empirically, with constant inspection and adaptation.

[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.]

How does Scrum differ from Critical chain?

CC aims to get the project finished as quickly and reliably as possible. Scrum aims to get working functionality delivered as quickly as possible.
CC buffers with time. Scrum buffers with functionality.
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".

Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don�t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects.

[Good concise comparison.]

Write Clarke at clarke@chingz.com.

Day Two Daily Scrum

Lean Project Management

I Hired a Certified ScrumMaster

Another Scrum Day of Learning

Towards a New Theory — A Look at Scrum

This entry was posted on Friday, November 14th, 2003 at 10:07 am and is tagged: agile, Theory of Constraints. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed. Convert this post to a PDF document.

Social Bookmarking

7 Responses to “How Do Scrum and CCPM Compare?”

Frank Winters Says:
November 14th, 2003 at 3:33 pm
Hal — ?Question:

Does this:
D - Allow change throughout project
B - Build functionality required by customer
A - Have a successful software project
C - Deliver on time and to budget
D’- Agree scope up-front and don’t allow change throughout project

mean that A-B-D rules out C? My unlettered reading of this is you can choose to follow A-B-D or A-C-D’ but not A-B-C-D. Is this incorrect?

Thanks,
Frank
Bill Seitz Says:
November 14th, 2003 at 4:49 pm
I don’t see the synergy. I see CC as a significant improvement to traditional planning in its use of slack.

But I don’t think it challenges the underlying assumptions in the ways that scrum/agile does (as your last 3 bullets show quite well). It seems to me like CC still depends on BigDesignUpFront, whereas agile does JustEnough thinking ahead to prioritize the functionality to deliver and concentrate on the plan/design for just that piece.
Clarke Ching Says:
November 14th, 2003 at 5:25 pm
Hi Frank,

It is easier to read the cloud if you see it graphically. I’ve popped a version here:

http://www.chingz.com/softwarecloud_files/image002.gif

The diagram shows that B and C are both necessary to achieve A. D is necessary to achieve B. E is necessary to achieve C. BUT D and E are opposites, i.e. they are conflict.
Hal Says:
November 14th, 2003 at 8:19 pm
Sorry for the confusion everyone. Walk again thru my word description under the chart or visit Clarkes picture referenced in the URL above.

The simple answer to Frank’s question is No. The two paths are incompatible. Now that the conflict is established the opportunity is to restate causal relationships (assumptions) so you get both B and C.

Clarke, you up for doing that for this blog?
Frank Winters Says:
November 15th, 2003 at 4:55 am
Thank you Hal and Clarke.

I understand the diagam now. We know that D and D’ are incompatable (mutually exclusive) but to me the diagram still says you can’t have all the functionality the users will want and deliver on time. That’s the point I was making.

However, if the development team and the users agree that time is not the issue as long as the business is supported, by incremental functionality deliver just in time, you should still have a successful project.

Or am I missing the point again?

Frank
clarke ching Says:
November 15th, 2003 at 11:32 am
Frank,

I think you’ve got the point.

If C is no longer dependent on D’, which is what you’re saying, then the conflict cloud - as drawn - no longer exists. It is evaporated.

Clarke
Clarke Ching Says:
November 18th, 2003 at 12:26 pm
Hi, I’ve just found out that Mike Cohn uses Scrum and Critical Chain concepts together, as discussed in (an old) draft of his user stories book:

http://userstories.com/download/WhyPlansGoWrong.pdf

Comment On This

If you haven't left a comment here before, you will need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.