Yesterday, I attended the Puget Sound TOC Update 2004 Learning Event at the Coast Hotel in Bellevue. I'd like to thank Steve Dightman for putting it together. I really enjoyed it and the content was excellent. There certainly is a strong TOC community here in Seattle - and they don't all work at Boeing :-)

Skip Reedy was the first speaker. His topic was transitioning to a Critical Chain multi-project (PMO) solution at Boeing. His main theme was that you don't just turn off the old way of doing things and switch to Critical Chain. You can't. All the projects in the portfolio simply don't finish on the same day to allow a clean switch over. At the beginning there will only be one CC project in a portfolio of traditional Critical Path projects. His key insight was that you need to change the way the organization thinks and talks about projects as a first step to switching over. He needed to change the mindset! His solution - let many projects run in CP mode but switch the reporting to a more CC friendly fashion. Kick the organization out of a focus on Due Date reporting. Working to Due Dates encourages multi-tasking and undermines the move to a prioritized pacer/constraint driven project portfolio. If you are reporting Due Dates you just can't change to CC! To change the mindset and the reporting approach he asked for a change in behavior to road runner behavior and reporting input and delivery rates. He did this by asking traditional projects to report as project days late or early (rather than Due Date) and percentage (of the Critical Path) complete.

What I took from this was the behavioral change to kick people out of the old mindset. My epiphany was that if road runner behavior is desired then you are asking the individuals and teams to focus on lead time and if input and delivery rate are being reported then you are focused on capacity (or productivity) of the constraint (whatever it may be) and the rate of input to the system. These are the control points which drive the Drum-Buffer-Rope solution. With DBR, the main control mechanism is the capacity of the constraint (or the rate of production through the constraint) and the rate of input into the system, plus a buffer based on the variance of the constraint - as I explained yesterday. The buffer is inventory and inventory is directly related to lead time - from Little's Law. Hence, could it be possible that implementing a DBR solution is the route to transitioning to a multi-project Critical Chain (CCMPM) solution?

To answer this we must consider what I've been doing with FDD and how I describe the process of Agile Management in the book.

First, I focus on quality and batch size. This frees up capacity in the constraint. Then I develop a Drum-Buffer-Rope production solution using Cumulative Flow to identify and track the constraint. This is basic FDD without much of Step 3 - Plan-by-Feature. Put another way - get a big list of Features for a release and build them tracking the Feature Milestones with the Cumulative Flow Diagram (CFD) and keep the WIP inventory small and the lead time under 2 weeks by monitoring the CFD. Focusing on keeping lead time short is asking for Road Runner behavior. Lead time is the metric of the Road Runner. How long did it take him to cover the distance? Only when you can do the DBR solution (FDD steps 2, 4 and 5) and show that it is stable is it really worth spending time on Plan-By-Feature and building a Critical Chain schedule by Feature Set. This squeezes extra productivity - or more accurately better value delivery - out of the system. It communicates a plan for partial value delivery of Feature Sets, or put another way, downstream batch transfers, to the quality assurance group and beyond. Moving to CC scheduling of Feature Sets facilitates a move to a multi-project solution with a managed shared resource as the overall system constraint.

So there are four steps

1. Free capacity in the constraint by improving quality and reducing batch size (you can do this blind without identifying the constraint)
2. Implement Drum-Buffer-Rope for the flow of value through the system of software engineering
3. Implement Critical Chain scheduling once the DBR solution is stable
4. Move to a multi-project Critical Chain scheduling solution as each project in the portfolio reaches step 3 in the transition

It's interesting to note that two of the most popular agile methods eXtreme Programming and Scrum essentially never get beyond the DBR solution. First they restrict batch size to 2 or 4 weeks of work and with XP there is a heavy focus on improved quality with Test First and Pair Programming. Next, they identify the velocity, treat development (a mass of analysis, design, coding and testing) as the constraint, stem off the flow at the input to the capacity of a 2 or 4 week iteration, and stabilize the system at that. The lesson here is that TOC would suggest that there is a lot further to go in squeezing the profits and return on investment from software development activity and agile development is only the beginning of that journey.