Softpanorama

Home

Switchboard

Unix Administration

Red Hat

TCP/IP Networks

Neoliberalism

Toxic Managers

May the source be with you, but remember the KISS principle 😉
Bigger doesn’t imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous
cells



Softpanorama

Home

Switchboard

Unix Administration

Red Hat

TCP/IP Networks

Neoliberalism

Toxic Managers

May the source be with you, but remember the KISS principle 😉
Bigger doesn’t imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous
cells


Agile Training | Agile Coaching | Agile Transformation

open menu

Agile Training | Agile Coaching | Agile Transformation

open menu

back to field notes
field

The Theory of Constraints and Brooks’ Law

WRITTEN BY Andrew Fuqua

  • Print

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 Theory 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 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. 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 Theory 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 1st Rule of the Theory 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 2nd Rule of the Theory 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 3rd Rule of the Theory of Constraints: Subordinate Everything to the Constraint.

The 4th Rule of the Theory 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 Theory 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 5th Rule of the Theory 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 Theory of Constraints?

  • Print

WRITTEN BY Andrew Fuqua Google+

@AndrewMFuqua is a founding member of XP-Atlanta in 2001. Currently an Enterprise Transformation Consultant, Andrew has previously held positions in management, product management and software development at companies like Internet Security Systems, Allure Global, and IBM. Andrew earned a BS and MS in computer science and has an MBA from Duke University.

leave a comment

Leave a comment

3 comments on “The Theory of Constraints and Brooks’ Law”

  1. Simplicity and the Single-tasking Project Manager | LexisNexis University Blog


    […] p.s., for more on Theory of Constraints as it applies to Project Management in an Agile environment check out Andrew Fuqua’s piece on The Theory of Constraints and Brooks’ Law. […]

    Reply

  2. Ryan Chase


    Solid explanation, and really interesting, thanks.

    Reply

  3. Hosk’s Recommended Dynamics 365 Articles July 2018 – Hosks Dynamic CRM Blog


    […] Theory of constraints and Brook’s law  […]

    Reply

Never Miss A Post
Enter your Email below to signup for blog updates via Email
Resources
View All

Videos

Why Agile is Failing in Large Enterprises and What You Can Do About It
Watch

Slideshare Presentations

From Agile2013 – Sustainable Change
View

Slideshare Presentations

The Agile PMP
View

FOLLOW @LEADINGAGILE

Project Management History

Welcome

9130BC-1899

Gobekli Tepe
The Great Pyramid
The Parthenon
Ulm Minster
Project
Project Engineer
USS Monitor
The Harmonogram

1900-1938

Kanban
The Trans-Siberian Railway
Work, Wages and Profits
The Panama Canal
The Empire State Building
The Hoover Dam
Chain Home

1939-1959

The Manhattan Project
Speedee Service System
Business Format Franchising
Critical Path Analysis
Program Evaluation Review Technique (PERT)

1960-1979

The Human Side of Enterprise
Phased Project Planning (PPP)
PROJECT/2
Chief Programmer Teams
The Mythical Man-Month and Brooks’ Law
PROMPT
Micro Planner
Global Eradication of Smallpox

1980-2015

IBM ISMA
Management Teams – Belbin Team Roles
Scrum
The E-myth
PRINCE
PMBOK
Extreme Programming (XP)
Critical Chain
Total Project Control

The Mythical Man-Month and Brooks’ Law

Frederick Brooks 1975

Frederick Brooks


Frederick Brooks

The Mythical Man-Month: Essays on Software Engineering is perhaps the single most
quoted text ever written about software engineering and the project managment of
large software projects. It is also one of the least implemented, prompting Brooks
himself to say, “everybody quotes it, some people read it, and few people go by it.”
Frederick Brooks’ (1931-) observations are based on his experience managing the
development of OS/360, an IBM mainframe operating system.

Although the book covers many topics, Brooks’ title theme, referred to as “Brooks’
Law” has become the best known of his ideas. The premise of Brooks’ Law is that
adding manpower to a late software project just makes it later, in large part
because of increasing issues with communication and their interference with project
focus. Another famous statement of the law is the analogy, “Nine women can’t make
a
baby in one month.”