Agile and Critical Chain

Introduction

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.

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[2] 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.[3]

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.[4]

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.[5] 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] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed (Addison-Wesley: Boston, MA, 2003).

[3] 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.

[4] And agile projects. For a non-software agile/critical chain case study, check Matt Gelbwaks, “Segway and an Agile Critical Chain” in the Cutter IT Journal.

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