Avoiding Brooks’ Law: Agile ways to speed delivery

In modern delivery teams, Brooks’ Law is one of those uncomfortable truths: adding more people to a late project often makes it later.

That sounds counterintuitive, especially in fast-moving GCC organisations where leadership pressure is often “just add capacity”. In complex knowledge work, extra hands can increase coordination effort, slow decision-making, and create more rework.

The good news is you can reduce the impact of Brooks’ Law without heroics. You do it by redesigning the work, tightening feedback loops, and protecting team stability.

Key takeaways

• Brooks’ Law is mostly a communication and onboarding problem, not a motivation problem.
• Adding people helps only when work is modular and onboarding is lightweight.
• Agile reduces the damage by making work smaller and easier to inspect and adapt.
• The fastest “fix” is often scope clarity + flow improvements, not headcount.
• If you must add people, do it deliberately with guardrails and clear ownership.

Challenge / why this matters

Brooks’ Law is commonly summarised as: adding manpower to a late project makes it later.

The practical point isn’t that adding people is always wrong. It’s that late projects usually fail because of uncertainty, dependencies, and coordination, and adding more people increases all three.

In the UAE and wider GCC, this shows up in a few familiar patterns.

• Large programmes needing alignment across IT, operations, procurement, compliance, and vendors.
• Transformation initiatives where the backlog is unclear, so work can’t be split safely.
• Teams still learning the domain, platform, or new ways of working.
• “Resource swirl” where people are reassigned weekly, so ownership stays shallow.

When leadership asks for more capacity, it often comes from a good place: reduce pressure, recover timelines, and restore confidence. But if the system is the problem, more people simply adds load to the system.

Approach / how it works

Brooks’ Law exists because communication paths and coordination overhead grow as the team grows.

More people typically means:

• More time aligning on priorities and design decisions.
• More handoffs, waiting, and “who owns this?” confusion.
• More onboarding, knowledge transfer, and context switching.
• More rework because different people interpret requirements differently.

Agile approaches help because they change the shape of the work and how teams coordinate. That reduces the cost of collaboration and the risk of misunderstanding.

1) Shrink work to reduce coordination

Late projects often contain oversized work items, vague acceptance criteria, and hidden dependencies.

Agile counteracts this by breaking work into smaller increments that can be built, reviewed, and improved quickly.

Practical ways to do this:

• Split work by customer outcome, not by technical component.
• Tighten “done” so quality expectations are clear early.
• Define acceptance criteria before starting work, not during testing.
• Prefer slices that can be completed in days, not weeks.

This makes parallel work safer. It also reduces onboarding cost if you do add people later.

If you’re seeing teams fall into “busy but not delivering”, it’s often a sign of oversized work and weak slicing discipline. A related failure mode is discussed in Read Mechanical Scrum traps ↗.

2) Stabilise teams instead of rotating resources

Late projects often trigger a “move people around” reflex. That creates temporary relief, but it usually destroys throughput.

Stable teams build:

• Shared context and domain understanding.
• Working agreements and predictable collaboration patterns.
• Trust, which reduces the need for heavy oversight.

If you need to increase capacity, consider adding stability first.

• Stop swapping people in and out mid-sprint.
• Reduce competing priorities so the team can finish, not just start.
• Protect focus for at least 2–4 sprints before changing team composition.

Stable teams also make Scrum Events (aka Ceremonies) more effective, because the same group is inspecting and adapting together.

3) Tighten feedback loops to cut rework

When delivery is late, teams often stop inspecting and start rushing. That increases rework and delays discovery of the real issue.

Agile reduces risk through short feedback loops:

• Daily alignment on blockers and next steps.
• Frequent reviews of working outputs, not just status updates.
• Retrospectives that focus on evidence, not opinions.

A practical mindset shift helps here: treat every sprint as a risk-reduction cycle.

If you want a real example of how shorter feedback loops reduce cycle time in a non-software environment, Read MTN’s procurement transformation ↗.

4) Make dependencies visible and manageable

Brooks’ Law hurts most when work is not modular and teams are blocked by each other.

Before you add people, make dependencies explicit.

• Visualise dependencies on a board, not in people’s heads.
• Clarify who owns each decision and each interface.
• Sequence work to reduce cross-team waiting.
• Agree “definition of ready” rules so work doesn’t enter the sprint half-formed.

In GCC organisations, this is often the hidden constraint: decisions live in committees, and delivery teams wait for approvals.

If you reduce approval latency and clarify decision ownership, you often get “capacity” back without adding headcount.

5) Add people only when the work design supports it

Adding people can work when:

• Work can be split into independent slices.
• Onboarding can be completed quickly.
• Interfaces and quality expectations are clear.

Adding people usually fails when:

• Work depends on the same specialist reviewers or approvers.
• The backlog is unclear, so new joiners create more questions than output.
• The team is already overloaded with meetings and status reporting.

If you must add people, do it deliberately.

• Add 1–2 at a time, not a surge.
• Pair new joiners with experienced team members for the first sprint.
• Give new joiners a contained slice with clear acceptance criteria.
• Protect time for onboarding rather than pretending it’s “free”.

Related reading

• Read multiple projects at once ↗
• Read Agile metrics ↗

Results / expected outcomes

Handled well, Agile approaches reduce the typical failure modes behind Brooks’ Law.

Reasonable outcomes to expect include:

• Clearer priorities and fewer “false starts”.
• Faster identification of delivery risks and blockers.
• Reduced rework through earlier feedback and stronger clarity.
• Better ownership and fewer handoffs across functions.

What you should avoid promising is an automatic speed boost just because you “went Agile”.

The gains come from better work design, fewer unmanaged dependencies, and tighter feedback loops.

Practical takeaways / what to do next

If a project is already late, these moves often help more than adding people.

1. Confirm the real constraint

Late delivery is usually caused by one dominant bottleneck. Identify it before changing capacity.

Common constraints in GCC environments include approvals, environment access, compliance review, testing, vendor dependencies, and unclear scope.

2. Reduce work in progress

If the team is juggling too much, add focus before you add people.

Limit parallel initiatives and protect time to finish priority items.

3. Split work into smaller increments

Smaller items reduce onboarding cost and make parallel work safer.

Aim for slices that can be completed within a sprint, ideally within days.

4. Stabilise the team for 2–4 sprints

Stop rotating people. Protect the team long enough to build shared context and delivery rhythm.

5. If you must add people, add them deliberately

• Add 1–2 at a time.
• Pair new joiners with experienced members.
• Give a clear slice with “done” defined.
• Build onboarding time into the plan.

If you want a quick, practical view of where your delivery system is creating friction, start with a lightweight diagnostic rather than a big reorganisation.

Relevant training courses

• View Professional Scrum Master ↗
• View Professional Scrum Master II ↗
• Explore Applying Professional Scrum ↗
• Explore Scrum facilitation skills ↗

Conclusion

Brooks’ Law is a reminder that delivery is a system problem.

When projects are late, the instinct to “add resources” is understandable. But without redesigning the work and the coordination model, it can add communication overhead, onboarding delays, and more rework.

Agile approaches reduce the impact by making work smaller, tightening feedback loops, and creating stable, cross-functional collaboration.

Contact us

If you want a pragmatic view on what’s actually slowing delivery (and what to change first), start with a short diagnostic conversation.

Book a 30-minute diagnostic call ↗

‍