The Law of Constraints and Brooks’ Law

In a video series on systems thinking, Tom Looy posed the challenge of explaining Fred Brooks’ Mythical Man Month in terms of the Eliyahu Goldratt’s Law of Constraints.

In The Mythical Man Month, Fred Brooks explains that while cost varies with the number of men and months, progress does not. “Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them… This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.” This gave rise to Brooks’ Law: Adding manpower to a late software project makes it later.

According to the Law 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. Breaking the constraint means to continuously improve the system such that the current constraint is protected or improved such that it is no longer a constraint. Then you should repeat the process for the next constraint.

Putting these two concepts together can help you understand both of them. That’s a good idea. What follows is a look at Brooks’ Law in terms of the five focusing steps from the Law of Constraints.

Often when there is a late project, managers add people to help with the current phase of development and/or the later phases. Typically, a project is late in development or about to enter system testing when it is discovered that it will run late. But management adds more people without considering what is the actual constraint. Dev and QA might not be the constraint. Perhaps development is held up by a review process, a third party, or delayed UI specs. Thus, they violate the 1^st Rule of the Law of Constraints: Identify the Constraint.

When managers add more people to a late project, there is seldom any adjustment of the rules and regulations or overhead that is affecting the constraint. In fact, more status meetings are usually added. Also, they have those who are the constraint work to bring the new people up to speed. They increase the burden and have the constraint do more than just those things that only the constraint can do. Thus, they violate the 2^nd Rule of the Law of Constraints: Exploit the Constraint.

Typically accompanying adding people is schedule compression. It’s common, then, to hear “Since we’re behind schedule, NOBODY better be idle!” So, everybody finds some way to be, or at least look, busy. This adds more work into the project which invariably has some impact on the constraint; it adds more code for the constraint to test, or it ends up having a dependency on the constraint, or the constraint has to field questions or support those who need to use some output from the constraint. Instead, they should leave slack in non-bottleneck activities to handle unplanned work. Thus, late projects and the add-people mentality ignores the 3^rd Rule of the Law of Constraints: Subordinate Everything to the Constraint.

The 4^th Rule of the Law of Constraints is Elevate the Constraint. There are many ways to do this: add more people, provide training, improve tooling and automation, procure faster workstations, etc. All of these things impact the constraint directly, and negatively so in the short term. Adding people tends to reduce the capability, efficiency, capacity, and throughput of the constraint in the short term due to the learning curve, time spent teaching and orienting, and time spent setting up new workstations instead of producing. More importantly, Brooks warns of the burden of intercommunication. Adding people increases the coordination required. “The added effort of communicating may fully counteract the division of the original task… Adding more people then lengthens, not shortens, the schedule.”

Thus, adding people seems to be core to Elevating the Constraint, but goes directly against the premise of  Brooks’ Law. But let’s look a little more closely. Adding people isn’t core to Elevating the Constraint; it’s just an option in some situations. The Law of Constraints is broadly applicable across industries and types of work; Brooks is concerned with scheduling and deadlines, and with software development in particular. The danger is that those involved with a software development project are intuitively familiar with Elevating the Constraint but haven’t internalized the lessons of the Mythical Man Month. If you have run up against Brooks’ Law, then you haven’t really elevated the constraint. So even here these two concepts are compatible.

The limitation at the constraint may just happen to be the number of communication paths in the system. Too many paths may be slowing down production. There are likely rules or procedures put in place to accommodate having so many people: code reviews by certain people, approval steps, written-over-verbal communication, branch and merge strategy, etc. Adding people reinforces those rules. This brings us to the 5^th Rule of the Law of Constraints: repeat the process but Don’t Let Inertia Cause a Constraint. Goldratt: “We cannot overemphasize this warning. What usually happens is that within our organization, we derive from the existence of the current constraints many rules. Sometimes formally, many times just intuitively. When a constraint is broken, it appears that we don’t bother to go back and review those rules. As a result, our systems today are limited mainly by policy constraints.” As an example, consider our hiring practices. Adding people lessens the likelihood that the organization will look for generalizing specialists that will swarm a problem. Fewer people encourages swarming, whereas more people encourages specialization.

What do you think? How else might you relate The Mythical Man Month to the Law of Constraints?