How Do Scrum and CCPM Compare?
Fuente: http://www.reformingprojectmanagement.com/2003/11/14/273/
How Do Scrum and CCPM Compare?
A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM).
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
[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.