The Real First Step in The Theory of Constraints

Before I make the case that there’s a secret, first step in the Theory of Constraints (ToC)—that a lot of people seem to dismiss—I’d first like to run through a little thought experiment.

Tell me, what’s wrong in the following situation? What would your prescription be?

I once worked on a Point-of-Sale product with quarterly releases. We used pair-programming, in a team of up to 12 co-located programmers. We had a very large open team-room, with lots of windows, but enough shade so that afternoon heat and glare wasn’t an issue. We had a strong suite of micro-tests that ran in seconds, had a decent suite of developer-written function and integration test automation, and had excellent internal and external quality.

We had QA expertise verify stories in-sprint, though a deeper test of each story sometimes lagged a sprint behind. In spite of this, every release had a 3-4 week manual regression and performance testing phase, which include adverse condition testing with assorted devices like specialty printers and scanners, and a 3-4 week user acceptance test performed by our main client.

Some, issues were found in the regression testing, but not many.  I don’t remember the exact number, so let’s just say it was around four issues each quarter, and only one of them would be considered severe. Rarely would the user acceptance tests find any issue that would require a fix. Production issues were also very rare; we’re talking maybe as many as one incident per quarter.

Identifying the Problem

So, what’s the problem and how would you solve it?

Well, let’s look at this from a Theory of Constraints perspective. According to the Theory of Constraints, organizations are prevented from achieving more of their goal because of one or more constraints. The theory puts forth a process, the five focusing steps, for breaking the constraint. The 1st step is to identify the constraint.

Identifying the Constraint

So, in the example I gave—what’s the constraint?

You might think the constraint is the QA practices. Sprint-behind testing is an anti-pattern. And if the regression suite was automated, we could greatly reduce the time to market. UAT could run in parallel. It would be less costly to release, and releases could be more frequent. Surely that should be the business’ goal.

Too often I see agile proponents see everything from a naïve team-level, Agile-process perspective.

What’s the real problem? “Oh, it’s obvious that the problem is the length of your end of release test phase.” No, I mean what’s the real problem?

In the example above, due to seasonal busy periods, the client only wanted to provide training (to 10s of thousands of cashiers) on new business capabilities supported by new POS features in certain months. That’s a constraint, but not in terms of the ToC, as I’ll explain later. (It’s a business constraint, but not a constraint on their Goal.) That additional two months of delay wasn’t a concern to the one main client. And they didn’t want more frequent releases.

Choosing Your Bottleneck

As an aside, in the Theory of Constraints you get to decide where you want your bottleneck to be. Outside of knowledge work, that often happens by removing other bottlenecks until you get to the one that, once fully exploited, is too expensive (today) to elevate.

Therefore, you’ve chosen that as your constraint by choosing to not break that constraint.

In IT and other knowledge work, the process is stochastic and so the bottleneck may move around. Sometimes test might be the bottleneck, sometimes it’s the programmers, sometimes it’s the Product Owner, or the SME, or the DBA, etc. In such a situation you chose your constraint in a different way. You have more constraints you can attack, or simply manage. For example, you can elevate programming and let manual testing be the constraint, controlling throughput by deciding things like test activities, schedule, and completion criteria. Once set, you’ve effectively decided that the quality produced by the system is sufficient. This is balancing the system throughput by adjusting the amount of quality assurance activities, by setting the level of that the organization decides they want.

Alternatively, you can elevate testing, the DBA, the PO and the SME, and let programming be the bottleneck… the thing you pay attention to and manage carefully.

Identifying Your Goal

Back to my scenario, executive management’s perspective of the constraint was the rate of development. The executive team wanted more function in each release, not (necessarily) more releases. From their perspective, this constraint was impacting the business’ ability to win new clients for their product and related services. Which brings us to the Goal.

According to the Theory of Constraints, the Goal is to make more money now and in the future.

Additional revenue from additional clients is the real business goal in my example.

Prospective clients wanted to provide an upgraded service offering. One with features that would support innovative, new business/sales models and revenue streams in their existing businesses. And, they wanted ways to charge more for additional services

This illustrates how one’s perspective affects the way one sees a problem.

Don’t Just Do Something  

Don’t jump to the solution without identifying the problem. Don’t assume you know what the real problem or constraint is. Many Lean-Agile proponents just do something. They see something they can “fix”, and so they tinker with it. I like the quote “Don’t just do something. Stand there.” Observe. Find the real problem before doing something.

Before you try to identify the constraint, you must first identify the business’ true Goal. Then, frame everything you do in terms of achieving that Goal.

In the example scenario, the people performing the post-release testing activities were available. They had slack, but they couldn’t be eliminated due to other services they performed year-round. Their time was expendable on testing activities.

Here’s A Better Idea

So instead of shortening the release test phase, a better prescription would be to focus energy on finding the minimal marketable feature for everything built. Then elevate programming, increase innovation in product management, and allocate capacity for new client features—restricting capacity spent on existing client features.

Spending management’s attention anywhere else would take energy away from the actual goal.