Agile principles

The Twelve Principles of Agile Software are practical guidelines that support the four values in the Agile Manifesto. Where the values provide philosophical foundation, the principles offer more concrete guidance for how agile teams should operate. Published alongside the Manifesto in 2001, they remain relevant for modern product development.

Why it matters

The Manifesto's values are somewhat abstract. "Individuals and interactions over processes and tools" is directional but doesn't tell you what to do. The twelve principles bridge this gap, providing guidance specific enough to influence behavior while remaining general enough to apply across contexts.

Teams that understand the principles make better decisions when frameworks don't provide explicit answers. The principles explain the "why" behind agile practices, enabling thoughtful adaptation rather than mechanical compliance.

The principles

Customer satisfaction through early and continuous delivery of valuable software. The highest priority is satisfying customers by delivering value quickly and continuing to deliver it. Not satisfaction through promises or plans-through working software that solves problems.

Welcome changing requirements, even late in development. Change isn't failure; it's learning. Agile processes harness change for competitive advantage rather than resisting it. This doesn't mean accepting any change uncritically-it means creating processes that can adapt when changes make sense.

Deliver working software frequently. From a couple of weeks to a couple of months, with preference for shorter timescales. Frequent delivery creates feedback loops, reduces risk, and builds trust. Each delivery is an opportunity to learn and adjust.

Business people and developers must work together daily. Not handoffs between siloed groups, but ongoing collaboration. Daily interaction prevents misunderstanding, enables quick decisions, and builds shared ownership of outcomes.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Motivation comes from autonomy, mastery, and purpose-not micromanagement.

Face-to-face conversation is the most efficient method of conveying information. Rich communication beats documents for complex topics. When face-to-face isn't possible, strive for the highest bandwidth communication available.

Working software is the primary measure of progress. Not documents completed, not tasks checked off, not hours spent. The question is: did we deliver software that works and provides value?

Agile processes promote sustainable development. Sponsors, developers, and users should maintain a constant pace indefinitely. Crunch is a symptom of failure, not a strategy for success. Sustainable pace produces better results over time.

Continuous attention to technical excellence and good design enhances agility. Quick doesn't mean sloppy. Technical debt slows future development. Investing in quality enables the speed agile requires.

Simplicity-the art of maximizing the amount of work not done-is essential. The best code is no code. The best feature is one you don't need to build. Focus on what's truly necessary and ruthlessly eliminate waste.

The best architectures, requirements, and designs emerge from self-organizing teams. Dictated solutions are rarely optimal. Teams closest to the work make better decisions than distant managers or committees.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Continuous improvement is built into the process. Retrospection and adaptation aren't optional extras-they're essential practices.

Applying the principles

The principles inform decisions at multiple levels:

In product management, they argue for continuous customer collaboration, frequent delivery of value, and simplicity in scope. They support iterative discovery over comprehensive upfront requirements.

In engineering, they advocate for technical excellence, sustainable pace, and self-organizing teams. They support practices like continuous integration, refactoring, and automated testing.

In leadership, they suggest enabling rather than directing, trusting teams, and measuring progress by outcomes rather than activities.

The principles sometimes tension with each other. Technical excellence takes time; frequent delivery requires speed. Welcoming change can conflict with sustainable pace. Navigating these tensions requires judgment, not mechanical application.

Principles vs. practices

Principles guide; practices implement. Standups, sprints, and backlogs are practices that embody principles like daily collaboration, frequent delivery, and simplicity. But the practices aren't the principles.

Teams that understand the principles can adapt practices to their context. A distributed team might have standups at different times or asynchronously. A research team might use longer iteration cycles. The practices change; the principles remain.

Teams that follow practices without understanding principles often get poor results. They do standups that don't improve collaboration, sprints that don't deliver value, retrospectives that don't produce improvement. The forms are present but the benefits are missing.

Modern relevance

The principles were written for software development in 2001. Some language shows its age-"software" appears throughout, though the ideas apply more broadly.

Contemporary practice has evolved. Distributed teams challenge "face-to-face conversation." Continuous deployment goes beyond "every couple of weeks." DevOps extends development to operations.

Yet the underlying wisdom remains valid. Deliver value frequently. Collaborate closely. Embrace change. Pursue technical excellence. Reflect and improve. These ideas transcend their original context.

Klero supports agile principles by enabling customer collaboration (principles 1 and 4), helping teams understand what's truly necessary (principle 10), and providing feedback that informs reflection and improvement (principle 12).