The 12 Agile Principles: Guiding Values, Not Rigid Rules

The mental model

The 12 Agile Principles are not a set of rules but a value system for software development. Think of them as a compass, not a map. They guide teams toward a state of continuous value delivery and adaptability by prioritizing people, collaboration, and working software over rigid processes and comprehensive documentation.

How it works

The principles can be grouped into four key themes. First, a focus on the customer, achieved through early and continuous delivery of valuable software and welcoming changing requirements. Second, a focus on team dynamics, promoting daily collaboration between business and developers, building projects around motivated individuals, and trusting self-organizing teams. Third, a focus on process and pace, using working software as the primary measure of progress, maintaining a sustainable pace indefinitely, and regularly reflecting to improve effectiveness. Finally, a focus on technical craft, emphasizing that continuous attention to technical excellence and simplicity enhances agility.

When to use it

Use these principles as the 'why' behind your team's agile practices like Scrum or Kanban. When a ceremony feels pointless or a process is causing friction, revisit the principles to diagnose the problem. For example, if sprint planning is failing, are you truly collaborating with business people daily (Principle 4)? Are you maximizing the work not done (Principle 10)? They are the spirit of the law, used to guide decisions and resolve conflicts within a framework.

When not to use it

The principles are philosophical guides, not a prescriptive project plan. Do not apply them literally without context. For instance, insisting on 'face-to-face conversation' (Principle 6) in a fully remote, asynchronous team might be less effective than mastering written communication. The goal is the outcome (effective information transfer), not the specific action. Applying them as a rigid, dogmatic checklist is the opposite of being agile.

One canonical example

A team is two weeks from a release when marketing identifies a critical feature a competitor just launched. A plan-driven team might reject the change. An agile team, guided by Principle 2 ('Welcome changing requirements'), collaborates with stakeholders (Principle 4) to assess the request. They use Principle 10 ('Simplicity') to define a minimal version of the feature. Their success is measured by delivering this new valuable software (Principle 7), not by adhering to the original, now outdated, plan.