The Theory of Constraints says that in any system there is one constraint at a time (occasionally two). To improve overall system throughput you have to first find the constraint; make sure it is working full speed; then find ways of either increasing the capacity of the constraint, offloading some of the work onto non-constraints, or eliminating the constraint entirely.

In explaining the theory, Beck uses the analogy of washing, drying and folding clothes. You might have a high capacity washer and have the whole family help with folding, but if your dryer is a compact low energy model like you’d find in a cramped Dutch apartment, you’re not going to have a lot of system throughput.

Broken down, a typical sprint could be:

Planning (Planning with client, tasking, estimating hours)
Development (Actual coding, feedback from client, AC negotiations)
Completion (Demo, shipping the new feature set)

In some cases we have a constraint with planning. We sometimes don’t gather all of the requirements when talking with the client, or we spend an inordinate amount of time tasking or our task estimates end up being wildly off. While we might excel in the Development and Completion stages, we lose out on increased efficiency with the bottleneck that is Planning.

In other cases we might quickly get through Planning, but when it comes time for development and shipping the software we struggle with clients who are allowed to operate outside of our process or throw negotiations out the window in an effort to “just get things done”.

So, how can we identify the constraint(s)? This requires the disciplined tracking of time spent as a result of internal and external decisions, along with the willingness to introspect on the effect of those decisions with regard to the throughput of the “system”. In other words, track your time effectively and don’t lie to yourself.

Bob: “We sure spent a lot of time tasking this week, we didn’t even get started until Tuesday afternoon.”
Tom: “Well, we thought it was a good idea to review the code while tasking and have the entire team review the tasks afterwords.”

—

Jim: “So I guess we’re changing things up today, the client has got a demo tomorrow so we have to finish this tonight.”
Eric: “It’d be nice if we could really nail down a sprints’ worth of work for these guys, we never seem to get much momentum.”
1 Beck, K (2005). Extreme Programming Explained: Embrace Change (Second Edition). Upper Saddle River, NJ. Pearson Education, Inc.