Integrating Critical Chain into Scrum/Agile Practices

Question

I am primarily a software developer and software development manager. I use practices from Scrum and Agile development to manage my project. This means:

• Incremental releases every two weeks
• Estimating work in a vague, non-time-bound unit (eg. story points)
• Planning releases based on historical performance (eg. average points per week over the last six weeks)

I came across Critical Chain during my PMP training. Critical Chain has several touted benefits that are amazing; primarily, a 30-50% reduction of schedule when used properly.

I'm curious to know how I can take Critical Chain practices and roll them into my current Agile processes to get these benefits. Some points of conflict are:

1. Critical Chain hinges on the fact that you don't have enough time to complete the work (eg. they give you 2 days to complete 4 days worth of work). In Agile, if stories are not complete, they're simply cancelled or carried forward into the next sprint.
2. Critical Chain uses a buffer at the end of the project. (If your project schedule is eight weeks, they give you four weeks to do the work, and a four-week buffer at the end of the project.) In agile, you only have sprints (iterations) when you have work to do.

I'll add more points as I think of them. I'm not an expert on Critical Chain, so I'm not sure what other issues would conflict with Agile.

Answer 1

The Critical Chain Project Management demands higher flexibility of your team:

From Wikipedia Critical Chain Project Management:

A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule.

But also (from Wikipedia Critical Chain Project Management):

when they are running their "leg" of the project, they should be focused on completing the assigned task as quickly as possible, with no distractions or multitasking.

And also (from Wikipedia Critical Chain Project Management):

Because task durations have been planned at the 50% probability duration, there is pressure on the resources to complete critical chain tasks as quickly as possible, overcoming student's syndrome and Parkinson's Law.

What concerns me the most is the probability of the team end up doing a bad multi-tasking. See the Human Task Switches Considered Harmful article by Joel Spolsky:

From Joel's article mentioned above:

The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once.

As you specified that you are working with software development, try to make sure your development team will understand the Critical Chain process otherwise they will freak-out and start doing many tasks at the same time.

Also from Joel's article:

In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.

To eliminate your conflicts between Scrum/Agile and Critical Chain:

Critical Chain hinges on the fact that you don't have enough time to complete the work (eg. they give you 2 days to complete 4 days worth of work). In Agile, if stories are not complete, they're simply cancelled or carried forward into the next sprint.

This conflict can be solved if you assume the fact that a 4-days-task actually is a 2-days-task. The real work is done in less time than dimensioned.

From Parkinson's Law:

The Stock-Sanford Corollary to Parkinson's Law reads, "If you wait until the last minute, it only takes a minute to do."

Of course some tasks will take more time than expected, but Critical Chain assumes half tasks finish early and half tasks finish late.

Critical Chain uses a buffer at the end of the project. (If your project schedule is eight weeks, they give you four weeks to do the work, and a four-week buffer at the end of the project.) In agile, you only have sprints (iterations) when you have work to do.

The eliminate this conflict you will have to set your sprint in a way that you always have work to do.

With the reduced time to finish the tasks as stated on first conflict much more tasks will fill the sprint-backlog. The overall time for project completion will reduce, than set it as the ideal time for project duration and let the remaining time as buffer.

It is very important to set priorities on tasks, like must do (justification needed if not completed) and should do and could do (justification not needed if not completed).

Basically, you will run a pragmatic Scrum methodology under Critical Chain's eyes.

Answer 2

Actually, the buffer-concept works quite well with an agile development method like scrum. I'm not so sure about cutting estimates in half though, but we also apply something similar by using 'most likely' - 'worst case' estimates. Here's how we do it:

First we do proper project management by starting with a well designed Work Breakdown Structure (WBS) up till work package level. The list of work packages is our product backlog. These work packages are then estimated with a 'Most Likely' - 'Worst Case' range.

Our 'budget' is the sum of the 'Most Likely' estimates. The 'buffer' is calculated as the sum of averages - the sum of most likely. Some use 2 x standard deviations, as explained in the Cohn book recommended by Marcie (see chapter 17 Buffering Plans for Uncertainty).

Now to execution: lett's say that according to our team's capacity we can finish the project in 6 sprints (according to the most likely estimates) and our 'buffer' budget is good for another 2 sprints. Makes a total of 8 sprints to finish the job.

Usually we split up our projects into several technical phases (or more formal releases); each such a phase gets its own buffer.

Answer 3

My take is that there is a potential for good synergy between CCPM and Scrum

If we focus on the direction of how to improve Agile/Scrum using CCPM thinking:

The idea of project buffer versus task buffers - my recommendation is to avoid task estimates altogether. just use small tasks, without due dates, and pull them as fast as you can to completion. This avoids parkinson's law and deals better with variability.

Sprint Commitment in light of variability - commit based on the worst case scenario, but have a scope buffer of things that you can over-deliver in case the average happens. Plan for Murphy, but plan also for Murphy not showing up...

Release Commitment same way using Scope Buffers and Worst case/Average scenarios. I see release/project/delivery commitment much more important than sprint commitment, and much more deserving of buffering. You don't care about local optimization of the sprint (unless each sprint is a delivery), you can more about global optimization of the release/delivery. Start using Control Charts to learn capabilities to improve commitments and predictability.

Avoid bad-multitasking by enforcing priorities on the release backlog and sprint backlog, and limit the amount of stories that are in progress in the sprint, as well as features that are in progress in the release backlog. "Stop Starting - Start Finishing".

There are also aspects that are similar to the multi-project environment staggering approach and freezing - when using Kanban to manage the release end to end - limit the overall design in process in the system.

Scrum/Agile gives you a great headstart on typical CCPM - because of the work using end-to-end stories in the backlog, resource flexibility due to drive to collective ownership, and reduced need to synchronize due to Feature/Scrum teams, you get a much simpler critical chain, with lesser need for feeding buffers, resource buffers, etc.

If you do have dependencies between teams and other external entities, you can have a high level pert chart of your project, also known as "Lookahead Planning" in the Agile world. But if you see TOO MANY dependencies, it might be an indication that your teams are not formed ideally to deal with the work.

There is a lot more to this discussion, but bottom line - not enemies, but cousins... now the CCPM consultant will tell you CCPM is much stronger and Agile is a local solution, but be strong ;-) CCPM on its end has lots to learn from the Agile world - flexibility on the features/requirements, early feedback, team empowerment, all the great things that can improve a CCPM environment and help deal with variability and improve predictability and throughput even for a great CCPM implementation. I see Agile/Scrum as a way to apply the Process of Ongoing Impromevement (POOGI) in the CCPM world.

Hope this helps.

Answer 4

Its going to be a bit of a mish-mash but theory would seem to suggest that you could accomplish this by:

1. Shortening the sprint by x days e.g. 3 days
2. Using all or a portion of those 3 days as buffer
3. NOT allow stories to be canceled or carried forward. They must be completed within the sprint plus buffer.
4. Extend certain deliverables across several sprints (growing the stories) and build/manage a buffer that's made up of all the buffer days from all the sprints e.g. 9 days if you're using 3 day buffer and spreading the story across 3 sprints.

Would be great to hear any feedback on this approach in practice.

Answer 5

This probably won't be a popular answer, but if you're doing Scrum, throw out most of what you learned doing your PMP. They are completely different thought processes.

Critical chain processes assume that you have a huge, detailed schedule, with resource and task dependencies. In Scrum, you have a well-prioritized backlog, from which the most important feature / task is always completed next. The team communicates daily (if not more often) and shows features to the customer every two weeks or 30 days, and tasks/features are re-prioritized accordingly. This will squeeze the inefficiencies out of the process for you, much like critical chain would do in a traditional project management project.

Now, if you like the concept of "buffers", you can still use them with Scrum. I recommend the book "Agile Estimating and Planning" by Mike Cohn. He has some great techniques for dealing with estimates and "buffers" in an agile way.

Answer 6

I am late coming to this but I would highly recommend reading the book. It is learning wrapped in a story and is a quick read. It is not the worlds greatest fiction but it gets the point across without being textbook dry. I agree that these two methodologies are cousins and not diametrically opposed.

Answer 7

Scrum and Critical Chain are intended to solve different problems. With Scrum, you are dealing with a poorly defined product. Agile methods are intended to develop, as efficiently as possible, a product that is poorly understood at the start of the project.

With Critical Chain, you have a well defined product/goal of your project, but a great deal of uncertainty in how long the individual steps will take. Because of this, in large projects keeping your critical resources busy becomes difficult, as the results of work by other resources may not be ready when the critical resource needs it.

Critical Chain solves this problem using techniques from Goldratt's theory of constraints. Goldratt's original book is rather old, and the understanding of the technique has improved considerably since he published. However, the new results remain scattered throughout the specialist literature.

Oh yes, the divide by two thing simply comes from the common practice of taking your best estimate for a task duration and doubling it.

Answer 8

Critical Chain was invented to handle the ever-present issue of buffering tasks in a schedule with dependent tasks, and how early finishes could never be taken advantage of while late finishes slipped all dependent tasks. It 'works' by cutting all task durations in half, ensuring that most tasks won't finish early. The time removed is then added to a 'chain buffer' as the last dependent task in the chain. In order to track progress on the schedule, all tasks that are completed on or ahead of time are marked as late, but all tasks that finish late are marked as completed and the extra time (time in addition to that allocated for the task) is 'eaten' in the chain buffer.

The goal of Critical Chain was to ensure that no task had to wait because someone finished early. It only works when you have a lot of resources that can constantly switch from task to task. We get the same thing in Scrum by NOT assigning component tasks of backlog items to team members, instead having team members grab the highest-priority task that has not been started and that they can do once they finish their current task. This allows us to utilize a pull system as found in Lean/TPS, and ensures that 'ready' tasks are started as soon as an appropriate resource is available.

In short, you don't need, or want, Critical Chain inside a properly-implemented Scrum process... it is a solution to a non-existent problem.

Answer 9

If your project:

1. can be handled by one team
2. can be split in a way so that each part can be handled by one team

Then Scrum is the way you go (of course if you need agile too).

Multi-team, multi-project scenarios with high inter-dependencies require synchronization between the teams. Critical chain project management is a playbook for such a scenario. Use it when needed, but don't play by it if you do not need it.

That said:

Agile task estimation is coarse - you can map this to buffer estimation. The popular modified Fibonacci series e.g. would give you aprox. 30% buffer size. Map this to the number of sprints you need to complete a "task". E.g.: Team A will need 3 sprints to deliver feature X: add a buffer of one sprint for calculating the deadline.

You might regularily re-evaluate dependencies in cross-team sprint retros or the like, re-plan your task-net and thus update buffers deadline expectations.