Introduction

Nowadays, agile software development techniques routinely bring a number of important benefits to software development organizations. By focusing on frequent iterations (short-term code releases), the cycle time for certain key aspects of development is shortened. This shortens distance between developers, who are creating code and features (along with bugs); and customers, who need working applications to solve real-world problems.[1] Rapid communication (e.g. through co-location) allows faster responses to changing situations. Intermediate releases can even be delivered to customers to provide critical features more quickly.[2]

Some say that agile is fundamentally at odds with critical chain scheduling because they incorporate fundamentally different approaches to planning. With agile, the emphasis is on flexibility and - well - agility. Things change. You prioritize features and plan iterations, understanding that plans may shift at any time with shifts in risks, business needs, customer requirements, and technology. With critical chain you create longer-term activity networks that are, typically, resource loaded.

Boehm and Turner[3] make a strong distinction between plan-driven and agile methods. This implies a full-blown conflict: do you plan, or are you agile? The authors present ideas for creating a balance between agility and discipline, which sounds like a good idea but also raises suspicions of compromise. I suggest that the reality is not “either-or.” There are no conflicts between critical chain planning and agile, but there are myths. I’ll talk about a couple of myths and suggest an approach for using critical chain scheduling in an agile world. 

Myths 

Myth: Critical chain is incompatible with fundamental agile principles.

Reality: I like to go back to the agile manifesto, http://agilemanifesto.org/principles.html, to consider this. When I do, I can see only a couple of issues that might cause friction:

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
With critical chain, we do try to make commitments far in advance. However, you can always change tasks and requirements. The schedule is a tool, not a straightjacket. If your long-term commitments need to change, change them. (But I also recommend you define clearly what you mean by “commitment.”)

7. Working software is the primary measure of progress.
This reflects the agile emphasis on customer needs trumping documentation and process. From that perspective, I don’t see a conflict. On the other hand, the real measure of progress - the critical chain and ProChain emphasis - is satisfaction of the most important business needs of the developers’ company, which usually translates to satisfying customer needs. Be careful not to interpret this principle to mean, “more working software = more progress.”

Myth: Critical chain implies that you have to plan each iteration in detail, far to the future.[4]

Reality: This isn’t a real requirement. The critical chain schedule provides the longer-term picture; detail comes from shorter-term iterations. As you complete features and higher-level tasks via iterations, as customer needs shift, the critical chain schedule is updated accordingly. When you first start work to construct a critical chain schedule for a release, you may not know all the requirements in detail. That shouldn’t be a problem; in the worst case, you can add very high-level tasks to the schedule to estimate the work and fill out the detail later. You may also find it difficult to make iterations work with a critical chain schedule unless the iteration plan is kept separate from the schedule. Again, that shouldn’t be a problem, as long as both provide credible information.

It could be useful to go the other way and look at critical chain principles relative to agile. But the truth is, I don’t see any conflicts between agile and the six principles discussed in The Billion Dollar Solution (Ownership, Leverage, Priorities, Status, Planning, and Uncertainty). 

When and How to Use Critical Chain with Agile

Let’s be more concrete and talk about when and how to use critical chain with software development. We should recognize that it’s hard to give a detailed prescription, because there are many variations of agile and there are many types of software development projects.[5]

To start, if you don’t have (or want) a well-developed agile methodology, I would recommend critical chain (and, of course, ProChain Project Management), for the kinds of reasons discussed in The Billion Dollar Solution. If you already use agile, critical chain will be valuable for software development projects if you need any of the following: 

• A long view of your projects, to reliably predict releases months or years to the future;
• A view of resource loading, both to pace projects and to staff appropriately;
• A means of setting priorities between projects, to reduce churn and multitasking; or
• Transparent, credible communication and discussion of resource needs and release dates.

Regarding “how,” think of the critical chain schedule as the high-level picture that helps predict deliveries, predict resource utilization, and manage cross-project interactions. Think of agile as the lower-level picture that helps make sure the work is managed well and flexibly. To apply critical chain scheduling in an agile world, adapt these kinds of steps: 

1. Set overall release objectives based on business needs and real customer requirements. You may need to plan multiple releases over time.
2. Examine two types of priorities as you review features: priorities based on those business needs, and priorities based on risks.
3. Create a critical chain schedule for at least the critical, required features at a high level, with adequate buffer and approximate resource requirements. In general, schedule the higher-risk features earlier, to give more time to control the risks. New or risky development will require larger buffers.[6] Use focused (not padded) durations for tasks and take into account on-market support and documentation in your overall resource picture.
4. Plan short-term work in more detail, future work in less. Short-term detail can be added to the schedule as time goes by; this is sometimes known as the “rolling wave” approach. For many projects, it won’t be worthwhile to merge the iteration plans with the critical chain schedule. That’s fine, as long as they match approximately and both are reasonably credible. Just make sure both types of plans subordinate to the business priorities.
5. Add lower-priority features to a release only if you’re confident that you’ll still have the time and resources needed for downstream tasks such as testing, bug fixes, user documentation, and so on. This is the same principle as the common agile practice of dropping features for which there’s insufficient time. Testing, so often squeezed between development and release dates, should never be used as a buffer.
6. Look at aggregate resource capacity vs. requirements and pace releases according to global resource availability. 

Key Points 

• Agile and critical chain do not conflict.
• You don’t have to include your detailed iteration planning in your critical chain schedule.
• Testing is not a buffer.
• If you’re going to be agile, it helps to stay flexible in the way you approach scheduling. 

Notes 

[1] This is very much analogous the advantages of shorter batch sizes for manufacturing; see Eliyahu M. Goldratt and Robert E. Fox, The Race (North River Press, Croton-on-Hudson, 1986), see also David J. Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Upper Saddle River, NJ: Prentice Hall, 2004), chap. 23.

[2] For a quick, useful read, see http://www.rocksintogold.com/.

[3] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed (Addison-Wesley: Boston, MA, 2003).

[4] For example: “The underlying assumption [behind critical chain] is you can define all the work and their dependencies. This is counter to the underlying agile assumption that the end state keeps changing.” http://forums.construx.com/forums/t/775.aspx.

[5] And agile projects. For a non-software agile/critical chain case study, check Matt Gelbwaks, “Segway and an Agile Critical Chain,” Cutter IT Journal, March 2003, 24-28, available at http://www.billiondollarsolution.com/downloads/cutter_it_0303.pdf.

[6] Buffer sizing is discussed briefly in The Billion Dollar Solution, I also cite chapter 4 of Anderson’s book. 

Other references:

Frank Patrick has blogged on this topic; see, for example, http://www.focusedperformance.com/2003_06_01_blarch.html#105602920068889601.
Clarke Ching has also written about agile and critical chain; see http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=13948.
And … you’ll also find information on David Anderson’s site, www.agilemanagement.net.

If you’re familiar with critical chain and Theory of Constraints (TOC) literature, you may have noted a number of topics that The Billion Dollar Solution doesn’t bring up, topics that are virtually always included with discussions of critical chain. Let me describe a few such topics and explain why I didn’t include them. 

SEP Terms

Student Syndrome is the tendency of people, notably students, to delay working on things until as close as possible to the time they’re due. Parkinson’s Law states that “work expands so as to fill the time available for its completion.” Both terms are used to demonstrate problems that cause projects to take longer than they need to.

In one of his Hitchhiker’s Guide books, Douglas Adams invented the SEP Field. You can make something invisible by constructing a SEP Field around it, because then it’s Someone Else’s Problem. Parkinson’s Law and Student Syndrome are SEP Terms. We acknowledge that these things are done frequently - by someone else. Lots of people put things off until the last minute or allow their work to use up safety time, but not me. (Or when I do, I have a really good reason, so that doesn’t count.)

SEP Terms can be very descriptive; the problem is that they cause us to think of problems as Someone Else’s. If you teach someone using SEP Terms, you’re likely to get them to agree that people – other people – should change. At best, they’ll become consultants.

I prefer to stick with terms that help people think about what’s happening, and what should happen, in shared terms. Do you and your colleagues multitask? Of course. Do you struggle with due dates and milestones? Probably. Do you feel like your task lists are a train schedule, as opposed to a relay race? Could be. These shared behaviors are easy to acknowledge, and it’s easy to understand why they slow things down. 

The Five Focusing Steps

The Five Focusing Steps of TOC (Identify, Exploit, Subordinate, Elevate, Go back) are fundamental to its scheduling applications. They have great value that many people have demonstrated in many environments. Why aren’t they even mentioned in The Billion Dollar Solution?

There are two reasons. The first is the simplest: they are dealt with well in many other places, including Project Management in the Fast Lane. The second reason is much more important: in my experience, most project organizations have a lot of work to do before they get to the point where the Five Steps (and many associated TOC concepts, like Throughput Pricing) are really helpful. Starting out with the Five Steps would be like teaching someone snowboarding before getting them winter clothing. They will notice that something is missing. (Yes, it is winter here in the Northeast.)

I do discuss the most crucial of the Five Steps, subordination. I don’t go into it a lot because subordination is - drum roll - a SEP Term. (Other people have a subordination problem, I don’t.) In fact, large parts of the book are spent discussing indirect leverage points: the changes needed to policies, procedures, and culture to help people subordinate to the goal of the organization. That’s where most organizations will need to put a lot of effort. For example, many companies have well-developed milestone systems; you won’t get anywhere near the improvements that are possible without changing those systems and the policies, behaviors, and beliefs that support them. There is a low-risk, low-threat approach to understanding why certain policies and behaviors have to change: try piloting critical chain scheduling (or ProChain Project Scheduling), as described in Chapter 17 of The Billion Dollar Solution.

Happy New Year!

I’ve just read the article, “Teaching Critical Chain Project Management: An Academic Debate, Open Research Questions, Numerical Examples and Counterarguments,” by William Millhiser of Baruch College at The City University of New York and Joseph Szmerekovsky of the College of Business, North Dakota State University. You can find it at http://blsciblogs.baruch.cuny.edu/millhiser/files/2008/10/teaching-ccpm-millhiser-and-szmerekovsky-2008.pdf.

The paper describes some of the tools the authors use to teach critical chain, using Goldratt’s book Critical Chain as a text. They discuss the related project management literature and examine the validity of some claims in the book.

This is a thoughtful piece by people who have studied and taught critical chain scheduling and who have dealt with many of the pedagogical issues in an academic setting. The article points to the need for better communication about critical chain concepts. Some of its criticisms are valid and some aren’t, but here are a few topics that strike me as noteworthy:

1. “On time” (p.6)

The authors point out that the definition of “on time” is important and say, “Clearly, PERT/CPM project management is geared to completing projects on time with minimum cost.”

I had a kind of slap-in-the-face moment some months ago regarding “on time,” namely the difference between on time as a measurement and on time as an objective. Critical chain scheduling is usually targeted towards delivering as quickly as possible; on time is not a direct objective. However, reliability (on-time performance) is an important associated benefit and we do measure it. But critical chain represents a huge shift from CPM, which often (as above) which has “on time” (along with minimum cost) as an objective. An “on time is as good as early” mentality wastes opportunities for early starts and promotes procrastination and the use of intermediate due dates. All this can lead to various problems, many discussed in The Billion Dollar Solution. So, ironically, the “on-time” objective of CPM actually jeopardizes the on-time measurement. That’s something to watch out for in critical chain implementations as well.

2. Buffers (pp. 6-7)

Buffers seem to be implicitly conflated with buffer sizing. The authors present some good arguments against the rule “cut tasks by 50% and put half of what you cut into the buffers,” but they lump those in with criticisms of buffering in general. This is like taking the concept of insurance and saying it may be bad because someone has done a poor job of setting rates.

I do believe that if you cut people’s task durations by 50% as a standard approach, you run a huge risk of destroying the credibility of your schedules. More generally, poor schedule building or buffer sizing in any form can make buffering ineffective. However, the validity of the buffering concept is easily demonstrated and should be considered independently of the mechanism used to size buffers.

3. Multitasking (pp. 10-11, 15-16)

Is multitasking always bad? It depends how you define it. I don’t accept “working several things at once” as a definition, because people aren’t capable of doing that. If you define it as switching back and forth between tasks without completing any of them, it usually is bad. If you define it (as I do in The Billion Dollar Solution) as “A practice of interrupting work on one task in order to work on another task,” it isn’t necessarily bad. The authors demonstrate a case where such task switching makes sense. That’s why some use the term “bad multitasking” to refer to cases where multitasking doesn’t make sense.

I prefer to avoid trying to characterize when multitasking is bad and when it’s good, because I don’t know how to do that without considering the specific situation. It’s not always even clear what a task is, which makes it impossible enumerate all the cases. The best answer, in my opinion, is for people to understand the full ramifications of task switching (and, by the way, interruptions) and make informed decisions. Do you think you have to switch in the middle of a task? So do it. But also analyze the downside, and figure out whether there are things you - and others in your situation - should do to avoid problems in the future.

4. What is CCPM?

The authors talk about Critical Chain Project Management (CCPM) but don’t define it. As they point out, Goldratt’s book includes little about risk management, purchasing, portfolio management, or setting project objectives. The truth is, Critical Chain was never intended as a comprehensive project management textbook; in fact, it never uses the term CCPM. So we have to ask: what is CCPM?

My answer is, I don’t know. Everyone has their own ideas about what’s included and what’s important. That’s why The Billion Dollar Solution is about ProChain Project Management, a project management improvement methodology that includes critical chain scheduling as one tool - admittedly, a central tool - in the toolbox.