Gall's Law

"A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be made to work. You have to start over with a working simple system." 1

John Gall

Agile teams often struggle with balancing innovation and complexity. Gall's Law warns against overengineering and highlights the importance of iteration, adaptation, and simplicity. It teaches agile teams that big, upfront designs often fail, while successful systems evolve incrementally from working solutions.

Impact on Agile Teams

Agile methodologies emphasize incremental development, simplicity, and adaptability. However, many organizations and teams still struggle with:

  • Overengineering solutions before validating their feasibility.
  • Skipping iterative evolution, leading to failed large-scale initiatives.
  • Complexity hindering agility, making it hard to pivot or adapt to change.
  • High failure rates in projects that start with grand, fully planned designs.

By understanding Gall's Law, agile teams can avoid unnecessary complexity, focus on building working increments, and evolve their solutions based on feedback.

Scenario

A company wants to implement a large-scale microservices architecture for a new product. The leadership team insists on designing the entire system upfront, complete with interdependencies, integrations, and automation.

The team spends three months designing before writing a single line of code. When development begins, they realize:

  • Some assumptions were incorrect.
  • The integrations are more complex than expected.
  • The system is difficult to test incrementally.

As a result, deadlines are missed, scope is constantly changing, and the product never reaches a working state.

Had the team started with a simpler, functional monolith and evolved it into microservices based on actual needs, they could have validated assumptions early and delivered value incrementally.

Ways to Mitigate Gall's Law in Agile Teams:
  1. Start with a Simple, Working Solution:
    • Build a Minimum Viable Product (MVP) before scaling.
    • Validate hypotheses through small experiments.
    • Avoid premature optimizations.
  2. Emphasize Incremental Development:
    • Follow Agile principles: iterative cycles, continuous feedback, and adaptability.
    • Use frameworks like Scrum or Kanban to develop in small, testable increments.
  3. Apply Lean Thinking:
    • Reduce waste by focusing on delivering working software early.
    • Avoid analysis paralysis and decision-heavy upfront designs.
  4. Leverage Feedback Loops:
    • Engage stakeholders and users frequently for iterative improvements.
    • Conduct retrospectives to adapt processes continuously.
  5. Encourage Simplicity in Design & Architecture:
    • Follow the YAGNI (You Ain't Gonna Need It) principle.
    • Use modular and loosely coupled designs to allow flexibility.
Conclusion:

Gall's Law highlights the importance of starting small and evolving rather than designing complex systems upfront. Agile teams that embrace incremental development, simplicity, and continuous learning are better positioned to build successful, scalable solutions.

Key Takeaways:

  1. Simplicity first:
    • Build something small that works before scaling.
  2. Iterate and evolve:
    • Grow complexity organically based on real needs.
  3. Embrace feedback:
    • Continuous improvement prevents overengineering.
  4. Reduce waste:
    • Focus on delivering value early rather than excessive planning.

Summary

Gall's Law warns against designing complex systems upfront, reinforcing agile values of simplicity, iteration, and adaptability. Agile teams that start with a small, working solution and evolve it based on real-world feedback avoid failure, reduce waste, and deliver better products.