Gall’s Law and the beauty of simplicity: lessons for your software development projects

John Gall’s observation is a useful warning for modern delivery teams:

A complex system that works nearly always evolved from a simpler system that worked.

In other words, when you try to design the “full perfect solution” up front, you often create a brittle programme that is hard to change, hard to test, and expensive to fix.

Gall’s Law matters in software, operations, and transformation programmes across the UAE and wider GCC, where delivery teams face shifting requirements, multiple stakeholders, and fast-moving technology choices.

Key takeaways

• Gall’s Law is a practical reminder: start simple, then evolve.
• “Designing the whole system” up front increases delay, cost, and risk.
• Agile helps by delivering in small increments with frequent feedback.
• Scrum supports this through short cycles and clear inspection points.
• The goal is controlled evolution, not uncontrolled complexity.

Challenge / why this matters

Gall’s Law is often quoted in delivery circles because it matches what leaders see in real programmes.

Big initiatives start with a thick requirements pack, a big architecture diagram, and a confident plan.

Then reality arrives.

New regulations appear, suppliers change, integrations take longer than expected, and customer expectations move.

In the Middle East, this is common in digital government, fintech, aviation, telecoms, and utilities.

The delivery challenge is rarely a lack of ambition.

It is the cost of complexity introduced too early, before teams have a working, validated foundation.

When complexity is “designed in” from day one, programmes tend to suffer from:

• long lead times before anything usable is released
• late discovery of technical or operational risks
• heavy governance that slows decision-making
• rework caused by changing assumptions

If you want a practical diagnostic lens for delivery friction across teams, Explore Team Health Assessments ↗

Approach / how it works

Gall’s Law originated in John Gall’s 1975 book Systemantics: How Systems Really Work and How They Fail.

The central idea is simple.

Complex systems that succeed are usually the result of learning, iteration, and evolution.

Complex systems “designed from scratch” tend to fail because you cannot predict all interactions, dependencies, and edge cases up front.

Agile does not remove complexity.

It changes how you manage it.

Instead of betting everything on a full up-front design, you build a simple working system, then evolve it based on evidence.

1) Start with a working “thin slice”

A thin slice is the smallest end-to-end capability that delivers real value.

It is not a prototype that only works in a demo.

It is something that works in the real environment, with real constraints.

Examples of thin slices:

• a single customer journey that completes end-to-end
• one integration that runs with real data and audit trails
• one operational workflow that can be executed safely
• one reporting view that supports a real decision

This creates a stable base that you can expand.

It also exposes real constraints early, including security, compliance, and performance.

2) Use incremental delivery to evolve complexity safely

Incremental delivery is the practical response to Gall’s Law.

You deliberately add complexity in small steps, so risks are visible and manageable.

This typically means:

• releasing small increments frequently
• limiting work in progress to avoid half-finished work piling up
• validating assumptions as you go, rather than at the end

In Scrum, Sprints provide a natural timebox for this.

The key is to treat each Sprint as a chance to deliver a working increment, not just “progress”.

3) Build feedback loops into delivery

Gall’s Law is partly about learning.

If you do not get feedback early, complexity grows in the dark.

Scrum’s events are designed to make work inspectable and adaptable.

Used well, Scrum Events (aka Ceremonies) create regular opportunities to:

• validate what has been built against real needs
• surface risks and dependencies early
• adjust direction without a programme reset
• improve how the team works, not just what it delivers

This reduces the “big reveal” problem where issues only appear at the end.

4) Prioritise simplicity, not completeness

Many programmes fail because leaders insist on completeness before usefulness.

Agile teams prioritise what matters most first.

This creates value earlier and reduces risk.

Practical ways to enforce simplicity:

• define what “must be true” for the first release
• separate “core capability” from “nice to have”
• make trade-offs explicit, not hidden
• focus on outcomes, not feature count

This approach is especially helpful when stakeholders have competing expectations.

5) Support self-managing teams with clear guardrails

Complexity is not only technical.

It is organisational.

If every decision must escalate, teams cannot respond quickly to what they learn.

Scrum promotes self-managing teams.

That does not mean “no governance”.

It means governance that sets boundaries, then allows teams to execute within them.

Effective guardrails often include:

• clear decision rights (what the team can decide vs what requires escalation)
• lightweight standards (security, data, quality, auditability)
• fast escalation paths when risk thresholds are reached
• a shared definition of done that prevents hidden work

If you work in a regulated environment, Read Agile and compliance guidance ↗

Results / expected outcomes

When teams apply Gall’s Law thinking with Agile ways of working, outcomes are usually visible in delivery flow and stakeholder confidence.

Common improvements include:

• earlier release of usable capability
• fewer late-stage surprises and less rework
• clearer prioritisation and fewer “big bang” dependencies
• improved predictability through short planning horizons
• better stakeholder alignment through frequent inspection

These outcomes matter most in complex, multi-stakeholder programmes.

They also matter when commercial and supplier dependencies are heavy.

A useful case reference for evolving operating patterns without losing control is Read the MTN procurement case study ↗

Practical takeaways / what to do next

If your programme feels stuck in complexity, these steps are a practical starting point.

1) Identify where complexity is being introduced too early

Look for signals such as:

• long periods of design with no working output
• heavy dependency mapping that never stabilises
• multiple workstreams waiting on shared components
• frequent rework caused by assumptions changing
• teams optimising for documentation over delivery

The goal is not to remove design.

It is to reduce “speculation”, where you decide too much too early.

2) Define a thin slice and make it non-negotiable

Choose one thin slice that is:

• valuable to a real user group
• deliverable in a short timeframe
• measurable (you can tell if it worked)
• realistic about constraints (security, compliance, integration)

Then protect it from scope creep.

This creates a working baseline you can evolve.

3) Make feedback real, not ceremonial

If Sprint Reviews are status updates, you lose the benefit.

Aim for reviews that show working outcomes and invite concrete feedback.

Good questions include:

• what did we learn that changes our next priorities?
• what risks or constraints became clearer?
• what should we stop doing because it is not adding value?
• what decision do we need from stakeholders this week?

4) Use a Definition of Done to control complexity

A Definition of Done reduces hidden work and late surprises.

In complex environments, include criteria such as:

• security and performance checks completed
• audit evidence captured in agreed locations
• operational readiness tasks completed (monitoring, support)
• documentation that is essential for compliance and handover

This is how you avoid shipping complexity that the organisation cannot safely run.

5) Review the operating model as you scale

As you add teams, complexity increases.

Do not wait until it is painful.

Review quarterly:

• where are decisions getting stuck?
• where are dependencies slowing delivery?
• what work is repeatedly reappearing as rework?
• what governance is adding value, and what is just delay?

If you want a structured baseline across teams and governance, Explore Agility Maturity Assessments ↗

Relevant training courses

• Professional Scrum Master ↗
• Applying Professional Scrum ↗
• Professional Scrum Facilitation Skills ↗
• Professional Agile Leadership Essentials ↗

Conclusion

Gall’s Law is not anti-ambition.

It is anti-fragility.

If you want a complex system that works, build a simple system that works first, then evolve it.

Agile, and particularly Scrum, supports this by creating a delivery rhythm that prioritises working increments, feedback, and continuous improvement.

That is how complexity becomes a controlled evolution rather than a programme-wide risk.

Contact us

If your teams are struggling with complexity, slow decision-making, or heavy rework, we can help you design a simpler starting point and an iterative path forward.

Book a 30-minute diagnostic call ↗

‍