Chesterton's Fence

"Don't ever take a fence down until you truly know the reason why it was put up."

G.K. Chesterton

When organizations embark on Agile transformations, they often seek to modify frameworks, roles, and practices to fit their specific needs. However, making changes without fully understanding why these structures exist can lead to unintended consequences. This is where Chesterton's Fence becomes a crucial guiding principle.

Chesterton's Fence warns against removing structures without knowing their original purpose. If a practice, role, or framework has stood the test of time, it likely serves a purpose that is not immediately obvious.

Impact on Agile Teams & Organizations

With Agile, many teams and organizations fall into the trap of dismissing established practices such as Scrum events, backlog management, or leadership roles before they fully grasp their value. This often results in:

  • Misalignment between teams and stakeholders.
  • Increased delivery risks and inefficiencies.
  • Teams working in silos, lacking cross-functional collaboration.
  • Leadership struggling to steer Agile initiatives effectively.

This challenge becomes even more pronounced when scaling Agile across multiple teams and departments. Organizations frequently customize scaling frameworks like SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum), and Nexus, among others, before they understand their intent. While adaptation is necessary, premature modification can lead to fragmented execution, poor alignment, and ultimately, Agile failure.

Scenario

A large financial institution decides to implement SAFe to improve coordination across technology teams and business units. However, leadership immediately starts modifying key aspects of SAFe without fully understanding their purpose.

  • Instead of a single ART-wide PI Planning event, teams conduct their own PI Planning in isolation, assuming they can handle dependencies later.
  • They remove the Inspect and Adapt event, which is designed to foster continuous improvement and alignment across teams.
  • They eliminate the System Demo, a critical ceremony for showcasing integrated features and gathering feedback from stakeholders.
  • They redefine the role of the Release Train Engineer (RTE) without considering the RTE's responsibilities in facilitating Agile ceremonies and removing impediments.

Consequences of These Changes:
  • Teams Misaligned on Priorities:
    • Without a Program Backlog guiding feature priorities, teams optimize only for their local goals.
  • Unresolved Dependencies:
    • Without an RTE facilitating ART syncs, dependencies cause bottlenecks and delivery delays.
  • Overloaded Product Owners:
    • Without a Product Manager for the ART, POs may focus only on short-term execution, losing sight of business objectives.
  • Slow Decision-Making & Reduced Agility:
    • Without clear leadership roles, escalations take longer to resolve.

Over time, the organization realizes that these modifications have weakened SAFe's effectiveness, requiring costly adjustments.

Ways to Mitigate this Risk:
  1. Understand Before Modifying:
    • Before changing a framework, leadership should study the rationale behind its roles, events, and practices.
    • Ask: What problem does this process/role solve? What happens if we remove it?
  2. Ensure PI Planning Is ART-Wide, Not Isolated:
    • All teams in the ART should participate in a single PI Planning event to align on objectives, dependencies, and business priorities.
    • Include business stakeholders to ensure feature priorities match strategic goals.
  3. Retain Critical SAFe Leadership Roles:
    • Ensure the RTE facilitates ART syncs, removes impediments, and fosters cross-team collaboration.
    • Empower the Product Manager to set the ART vision, align teams on business objectives, and manage the Program Backlog.
  4. Use Iterative Change Instead of Immediate Removal:
    • Rather than eliminating elements upfront, experiment with small adjustments, measure outcomes, and refine based on feedback.
  5. Invest in Training & Agile Coaching:
    • Educate leadership and teams on why SAFe is structured the way it is before making changes.
    • Engage SAFe Program Consultants (SPCs) or Agile coaches to provide informed guidance.
Conclusion:

Chesterton's Fence teaches us that before modifying an existing system, we must first understand its purpose. In scaling Agile, this means recognizing why frameworks like SAFe include specific structures, events, and roles.

While organizations should tailor frameworks to their needs, doing so without proper understanding can lead to misalignment, inefficiencies, and failed Agile transformations. A thoughtful, iterative approach ensures adaptability without losing effectiveness.

Key Takeaways

  • Don't remove structures without understanding their purpose.
  • Study the rationale behind Agile frameworks before modifying them.
  • Ensure alignment across teams and leadership roles in scaled Agile implementations.
  • Use iterative change to refine practices based on feedback.
  • Leverage Agile expertise to guide effective transformations.

Summary

Agile transformations often fail when organizations modify frameworks without understanding their core principles. Chesterton's Fence warns against removing structures without knowing their purpose, a critical lesson for companies scaling Agile.

When Agile frameworks introduce specific roles, events, and workflows, they are designed to solve real coordination, alignment, and execution challenges. While customization is often necessary, uninformed changes can lead to inefficiencies, misalignment, and diminished agility. Organizations must first understand the intent behind Agile structures, evaluate their impact, and iterate thoughtfully rather than making premature modifications.

By respecting the rationale behind established Agile practices and frameworks, companies can adapt without undermining effectiveness, ensuring sustainable and scalable agility.