Lehman's Laws of Software Evolution

Software evolves continuously; change is inevitable.

"A system that is not continually maintained will become progressively less satisfactory in use." ¹

Lehman's Laws of Software Evolution describe the patterns and pressures experienced by long-lived software systems. Derived from years of empirical research by Meir Lehman and Les Belady, these eight laws articulate how software must evolve to remain valuable, and what happens when it doesn't. Although first observed in traditional development environments, these laws are remarkably relevant to Agile teams today. They explain why complexity creeps in, why velocity slows over time, and why constant feedback is not a luxury, but a survival strategy. Agile methods may seem to counteract these forces, but in reality, they help teams adapt to them with intention and transparency.

Impact on Agile Teams

Lehman's Laws provide a deeper understanding of why Agile principles such as iterative delivery, technical excellence, sustainable pace, and cross-functional collaboration are essential. These laws show that Agile practices are not merely good ideas, they are direct responses to the natural entropy of software systems. Without disciplined adaptation, teams will see their systems become more complex, less understood, harder to change, and increasingly misaligned with user needs.

• Agile teams cannot assume velocity will remain stable without architectural upkeep.
• Backlogs will bloat unless informed by real feedback loops.
• Complexity must be counteracted with simplicity, not just speed.
• Organizational patterns, like siloed decision-making or overcommitment, will reinforce many of the negative trends Lehman observed.

Scenario

An Agile team manages a logistics platform that initially moves fast, delivering features every Sprint. Over the first year, they add route optimization, driver dashboards, dynamic pricing, and partner APIs. Success builds, but so does complexity. The codebase becomes brittle, onboarding new developers takes months, and refactoring gets pushed off Sprint after Sprint.

Despite two-week cadences, they miss three consecutive release goals. New features introduce regressions. Morale drops. Stakeholders grow impatient. The team is Agile in ceremony, but is being dragged by evolutionary forces they can no longer ignore.

This is not a failure of Agile, it's a failure to work with the system's nature.

The Eight Laws and Agile Implications:

• Continuing Change:
  • Software must be continually adapted to remain useful.
  • Agile treats change not as disruption, but as a constant.
  • Teams should:
    • Prioritize discovery regularly.
    • Revisit assumptions about the market and user needs.
    • Keep the product evolving to sustain value.
• Increasing Complexity:
  • Systems naturally become more complex unless simplified.
  • Agile teams must:
    • Invest in refactoring and clean code practices.
    • Apply modular architecture principles.
    • Protect technical excellence during Sprint Planning.
• Self-Regulation:
  • Delivery pace stabilizes based on real system constraints.
  • Agile honors this with sustainable pace and empirical metrics.
  • Teams should:
    • Monitor lead time and throughput.
    • Resist the urge to overcommit based on external pressure.
    • Use data to drive capacity decisions, not wishful thinking.
• Conservation of Organizational Stability:
  • Productivity remains relatively constant over time.
  • More backlog items do not mean more output.
  • Agile mitigates this by:
    • Enforcing WIP limits.
    • Encouraging outcome over output.
    • Helping stakeholders focus on value, not volume.
• Conservation of Familiarity:
  • Growth is constrained by how well the team understands the system.
  • Agile supports this by:
    • Promoting shared code ownership.
    • Rotating work across team members.
    • Using pairing and knowledge-sharing rituals.
• Continuing Growth:
  • Systems must evolve functionally to remain relevant.
  • But growth must be intentional, not additive for its own sake.
  • Agile teams can:
    • Align features with clear user outcomes.
    • Use experimentation to validate what adds real value.
    • Prune unused features and reduce surface area.
• Declining Quality:
  • Quality declines unless actively preserved.
  • Agile alone doesn't ensure quality, teams must:
    • Define quality explicitly (including non-functional aspects).
    • Maintain test coverage and observability.
    • Seek user feedback on performance, usability, and accessibility.
• Feedback System:
  • Evolving systems rely on fast, multi-directional feedback.
  • Agile rituals like Reviews, Retrospectives, and Backlog Refinement help, but need to be system-wide.
  • Teams and leaders should:
    • Integrate customer, delivery, and strategic feedback loops.
    • Make learning visible across silos.
    • Balance local improvements with global alignment.

Ways to Mitigate this Risk:

To adapt to Lehman's Laws without succumbing to them, Agile teams must adopt practices that sustain value over time:

• Embed refactoring and architectural review into the normal cadence of work.
• Use backlog management to limit cognitive load and enforce strategic focus.
• Monitor system health through both technical and user-centered metrics.
• Create strong alignment between product vision and delivery execution.
• Treat feedback loops as integral, not peripheral. Connect discovery, delivery, and customer success.
• Make team capacity visible and non-negotiable. Stability enables adaptability.

Conclusion:

Lehman's Laws are not warnings from a bygone era, they are ongoing truths of software development. Agile teams that internalize these laws become more resilient, more thoughtful, and more prepared for the long haul. These teams do not simply deliver features faster; they evolve systems that remain useful, usable, and adaptable. Agile is not a counter to Lehman's Laws, it is a way to live alongside them skillfully.

Key Takeaways

• Software systems evolve naturally. Evolution is unavoidable; decay is not.
• Agile helps teams navigate change, but only if paired with technical excellence and organizational alignment.
• Complexity must be actively reduced. Stability must be protected. Feedback must be systemic.
• Teams must plan for the long-term health of the system, not just the next sprint.

Summary

Lehman's Laws of Software Evolution describe the gravitational forces that shape all software systems over time. Agile methods provide a framework to adapt to those forces with intentionality. By understanding and addressing each law, teams can remain Agile not only in process, but in outcomes. These laws challenge teams to evolve wisely, build sustainably, and stay in step with both the system and its users.