Editor’s note: This article was last updated on 29 December 2022.
The Agile Manifesto marked the birth of Agile, a professional worldview that has sparked innovation in ways the authors didn’t expect and reached far beyond the world of software.
The Agile Manifesto specifies four values and 12 principles that guide efficient software product development.
In this comprehensive guide, we’ll introduce you to the concept of Agile product development and then break down the Agile Manifesto with a focus on its four values and 12 principles.
Before we get into the history of the Agile Manifesto and a detailed breakdown of how its tenets are implemented in practice, let’s quickly review its values and principles:
What are the 4 Agile Manifesto values?
The four values of the Agile Manifesto are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
What are the 12 Agile Manifesto principles?
The 12 principles of agile software development as outlined in the Agile Manifesto are as follows:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together dailythroughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximizing the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Click through the jump links above (or just keep scrolling) to learn more about what each of the 12 Agile principles means in practice and how to apply it in your organization. Many of these principles intertwine, so expect to see a lot of overlap.
What is Agile?
Agile is a mindset and philosophy around building products that espouses collaboration, customer-centricity, and expecting and responding to change.
A common misconception is that agile is about development speed or velocity; it isn’t. Also counter to popular belief, agile is neither a methodology nor a framework. These labels are reserved for more specific and prescriptive agile models.
For instance, scrum is an example of a popular agile “framework” — a set of instructions for putting the agile values and principles into practice. Thought leaders and consultancies create many agile models. These frameworks should not be confused with Agile itself.
What is the Agile Manifesto?
The Agile Manifesto is a short, 68-word statement that establishes a broad system of purpose and values for meaningful, efficient, continuous software development:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Don’t let the statement’s brevity fool you; these words pack a punch. The Agile Manifesto has changed the tech world and impacted how teams work across all industries, not only software.
A brief history
The Agile Manifesto established the concept of agile product development. The brief but bold declaration was written and signed in 2001 by 17 seasoned software engineers, some of whom have been writing code since the 1960s and ’70s. The machines and programming languages available at the time were as slow as the businesses they supported. Computers served elite science use cases more than business.
Throughout the 1970s and ’80s, waterfall, or “heavyweight,” practices dominated product development, where the emphasis was placed on upfront planning and documentation. Entering the new millennium, these experts had been collaborating on what were called at the time “lightweight” software development practices.
Popular lightweight frameworks of the 1990s were Crystal, Extreme Programming, and scrum, the most popular framework today. The creators of these leading frameworks and others were all signatories of the Agile Manifesto.
Today, agile is the standard. It all started with the Agile Manifesto.
Breaking down the Agile Manifesto
The Agile Manifesto consists of a simple preamble, four values, and one clarifying sentence. Let’s dig into each element and unpack what it means in more detail.
Preamble: Continuous learning is critical
The first sentence of the Agile Manifesto is the most overlooked and understated. Though seemingly insignificant, the signers have said this preamble actually took a considerable amount of time to write.
People often reference the four values without considering the introduction, but it’s important to establish a philosophy of constant change and improvement as well as generosity:
We are uncovering better ways of developing software by doing it and helping others do it.
Let’s get even more granular and zoom in on the first five words of the Agile Manifesto: “We are uncovering better ways….”
To embrace the Agile Manifesto means to commit to continuous improvement — in other words, to be joyfully and perpetually dissatisfied. From there, we should remember how much the discoveries of others have helped us. Share learnings; there are always new learnings to be had.
I’ve seen this play out in sprint retrospectives, postmortems, manager and/or peer feedback, evolving processes, and definitions of done (DoDs) — sharing learnings and listening to the understandings of others is crucial to any agile project. If you look around and see a lot of process that has gone unchanged for some time, you probably haven’t been “uncovering better ways.”
The world changes and life changes. To be agile means to embrace change and continuous learning.
The twist at the end
Throughout the four value statements, it can be easy to forget that none of these things are bad. The point of an even over statement is that one part is good, but the other is even better.
Before we dig into the four values, let’s skip to the bit at the end, where the Agile Manifesto tells us how to read the values correctly. This is also important but often forgotten:
That is, while there is value in the items on the right, we value the items on the left more.
As we review the four Agile Manifesto values, we should recognize that the right side is good, but the left is even more valuable.
The 4 agile values
The 4 values as stipulated in the Agile Manifesto are as follows.
1. Individuals and interactions over processes and tools
To be agile means to be all-in on people. The first value of the Agile Manifesto might be the most ahead of its time. The authors knew that people mattered and collaboration was essential.
We can infer more about the intention here by looking at the 12 Agile Principles, which are an elaboration of the fundamental values.
Of the 12 Agile Principles, at least six involve human relationships:
- Principle No. 4 establishes a new kind of relationship where “business people and developers must work together daily”
- Principle No. 5 says to “build projects around motivated individuals. Give them the environment and support they need”
- Principle No. 6 asserts that “face-to-face conversation” is the best way to communicate
- Principle No. 8 introduces the symbiotic relationship between “sponsors, developers, and users”
- Principle No. 11 claims the best deliverables come from “self-organizing teams”
- Principle No. 12 encourages teams to “[reflect] on how to become more effective” and adjust accordingly
It’s critical to remember how these even over statements should be interpreted. The right side of the statement (processes and tools) is valuable. However, individuals and interactions are more valuable. To rephrase this first Agile Manifesto value, we might say, “Processes and tools are good, but individuals and their interactions are even more important.”
In the real world, I’ve seen this play out in cross-functional squads made up of product, engineering, design, quality assurance, data analytics, and even marketing stakeholders — working day after day, in a single team, on a customer problem.
2. Working software over comprehensive documentation
While the first Agile Manifesto value is probably the most foundational of the four, the second value might be the most controversial today. The emphasis on “working software” often alarms modern tech professionals. What is so great about software that only “works?”
I have a friend who is a product manager at a large company. While developing their product, they spent up to a year digging into user research and discussing customer insights without shipping anything to the customer. In the end, they produced a small, insignificant feature that didn’t meet any real customer need.
So in cases like these, everyone wants to be a philosopher and empathize with customers, but no one can actually deliver.
Getting a minimum viable product (MVP) out now is better than getting a “perfect” product out much later. Of course, a “working” product is not the end goal, but it is required for delivering value to customers and businesses. If we’re not shipping, then what are we actually accomplishing?
Comprehensive documentation is good, according to the Agile Manifesto. This is how the even over statements work. For example, the second value could be rephrased as, “Documentation is good, but delivering working software is even more important.” A product with no documentation is preferable to having documentation and no product.
3. Customer collaboration over contract negotiation
In the third Agile Manifesto value, the reference to “contract negotiation” tends to perplex some readers. Keep in mind that the right side of the statement is still valuable, so contract negotiation is good. But what is this contract negotiation that we’re talking about?
Contract negotiation refers to any agreements involved in the work, internally or externally. Yes, this includes any political dealings and vendor paperwork, but there’s more to it than that. Many agile professionals would interpret contract negotiations to also include deadlines, budget agreements, and scope agreements with internal stakeholders or customers.
A modern paraphrase might be, “Business commitments are good, but the voice of the customer should come first.”
I’ve seen agile teams live out this value by prioritizing research and discovery work ahead of execution to ensure the right solution is built. I’ve seen granular Gantt charts replaced with quarterly and monthly Gantt charts or higher-level Now-Next-Later roadmaps.
4. Responding to change over following a plan
The fourth and final Agile Manifesto value asserts that following a plan is good, but responding to change is even more valuable.
Before the lightweight frameworks of the 1980s and ’90s, organizations might’ve spent years planning a solution, then years building the solution. By the time the original solution was ready, the problem had evolved enough to render the solution useless. These types of experiences and observations led engineers to seek better ways of developing software.
A well-known quote from former U.S. president Dwight Eisenhower comes to mind: “Plans are nothing; planning is everything.” The point is that plans are good to work on, but they should always consider the constant uncertainty surrounding them. Plans are only as good as their flexibility.
The 12 agile principles
To review and for quick reference, the 12 Agile Manifesto principles (in shorthand) are as follows.
1. Satisfy the customer
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
What does it mean?
As agile professionals, we believe in relieving customer pain by delivering valuable products and features quickly and regularly. Why? We can get feedback faster to improve and increase value to customers — and because we know that we never get it entirely right the first time.
How to apply Agile principle No. 1
- Focus on customers’ problems
- Build minimum viable products
- Operate with minimum valuable processes
- Foster a culture of learning and iteration in your team
2. Welcome changing requirements
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
What does it mean?
Embrace uncertainty. The environment is constantly changing, and change is something we can use to our advantage. To be competitive, not only should we anticipate change, but we should welcome it.
How to apply Agile principle No. 2
- Update sprint goals mid-sprint more frequently
- Set the tone for others by not being surprised when needs change
- Celebrate when your team pivots
- Use continuous discovery habits to stay in tune with customer problems and the market
3. Deliver working software frequently
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
What does it mean?
Take baby steps. There are multiple advantages to releasing more minor product updates more frequently. Shipping smaller increments regularly and being able to deploy quickly mitigates risk. Additionally, you can add value to the business by delivering more frequently and learning faster.
How to apply Agile principle No. 3
- Test how quickly your team can get a change live by making small changes (e.g., a comment in some code). This will help you gauge where you are and optimize your ability to respond to change
- Break up stories into smaller pieces. Need some inspiration? Consider what it might look like to only have one-point stories or only stories that can be delivered within a day
4. Work together daily
Business people and developers must work together daily throughout the project.
What does it mean?
Who is included in “business people?” I interpret this phrase to refer to anyone not on the tech teams — e.g., product, design, marketing stakeholders, etc. Of course, it depends on the organization, project, or outcome you hope to achieve.
No matter who is involved, transparency and collaboration should be day-to-day normalcy.
How to apply Agile principle No. 4
- Consider inviting other stakeholders to team meetings while managing expectations on roles and responsibilities as necessary
- Make planning and roadmap artifacts more accessible so others can follow along with progress and ask questions or provide feedback
- Create a visual of the team but include colleagues who might not technically be on the same team according to the official org chart
- Use an open Slack channel (or chat tool of choice) instead of keeping it private
5. Build projects around motivated individuals
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
What does it mean?
There are a lot of words packed in the fifth agile principle: motivation, environment, support, trust — with individual people at the center of it all.
A supportive environment will mean different things to different people. It comes down to knowing your team and how to communicate with and support the individuals within it.
How to apply Agile principle No. 5
You might find this principle the most challenging because it cannot be isolated to a specific level in an organization. For example, as a product manager, your hands might be tied in many ways.
That said, some things are always within your control. To improve the work environment as a manager, you can:
- Make work fun (whatever that means to you and your team)
- Treat people as individuals and get to know them personally
- Celebrate wins, big and small
- Establish a compelling vision for your product or program
6. Communicate face-to-face
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
What does it mean?
Video conferencing tools have made “face-to-face” conversations more effortless than ever, but they still don’t entirely replace in-person interaction.
At the same time, there are many advantages to remote work, so the takeaway isn’t that teams must be colocated, either.
How to apply Agile principle No. 6
- Turn your video on
- Meet in person from time to time
- Don’t be shy to jump on a quick call to hash something out in real time (using Slack’s huddle feature, for example)
- When using text, sprinkle in emoji reactions to avoid any confusion about your tone
7. Measure progress by working products
Working software is the primary measure of progress.
What does it mean?
Basically, it means to cut through the BS. The seventh agile principle stipulates that working software is the “primary measure of progress,” but some folks get alarmed because they read “only measure of progress” instead.
This principle can feel out of touch in a world where we value customer problem statements, fancy visual frameworks, user research, market research, analytics, and anthropology.
While these factors are important, what good are they if we aren’t getting any tools out into the wild to help customers in real life?
How to apply Agile principle No. 7
- Document and plan as you go
- Prioritize building things that will help customers now
- Double down on agile principle No. 1
- Apply healthy pressure to teams by asking, “Have we actually helped customers lately?”
8. Maintain a constant pace indefinitely (marathons, not sprints)
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
What does it mean?
Agility means that burnouts, late nights, and last-minute emergencies should be rare. The cross-functional team should plan to move at a sustainable rate. This can be supported by adopting the other agile principles, as well.
How to apply Agile principle No. 8
A common mistake people make when reading the eighth principle is to misinterpret the word “pace.” Most often, “maintaining a constant pace” means the team should slow down, not speed up. Plan ahead and put systems in place that make it normal to react to change.
9. Pay continuous attention to technical excellence
Continuous attention to technical excellence and good design enhances agility.
What does it mean?
You should take pride in your craftsmanship. Vince Lombardi, famed NFL head coach for whom the Super Bowl trophy is named, once said, “Perfection is not attainable, but if we chase perfection, we can catch excellence.”
The ninth agile principle doesn’t aim for perfection; we should acknowledge that excellence in the tech world is a rapidly moving target and to hit it requires “continuous attention.”
How to apply Agile principle No. 9
- Host lunch-and-learns and “brown bag” educational opportunities
- Build in time to incorporate tech debt into sprints
- Foster a culture in which team members are encouraged to maintain quality and sustainable implementations for longer-term agility
10. Keep it simple
Simplicity – the art of maximizing the amount of work not done – is essential.
What does it mean?
This phrase might seem counterintuitive at first glance and often strikes people as odd or unnecessarily confusing, but it’s actually pretty profound. Basically, it means less is more.
Maximizing the amount of work not done calls for a mental shift from doing more to doing less. Essentially, this means that you spend more time doing only what is necessary and waste less time complicating your processes.
How to apply Agile principle No. 10
- Understand the reason and the vision for what you’re working on
- Think about what is really needed. Consider a light framework, such as MoSCoW or Needs vs. Nice-to-Haves
- Determine the simplest solution to the problem and consider the tradeoffs
11. Trust your team to self-organize
The best architectures, requirements, and designs emerge from self-organizing teams.
What does it mean?
The best work comes out of teams that are allowed to plan and execute among themselves.
Principle no. 11 is not about anarchy or some progressive operating model where people form their own clans and do whatever they want — remember, this statement was written in 2001.
The point of the 11th agile principle is that motivated and supported individuals are trusted and allowed to immerse themselves in a problem space and come up with the best solution.
Trust doesn’t just magically emerge, of course, so this advice is sometimes easier said than done.
How to apply Agile principle No. 11
- Create organizations of teams that are motivated and empowered. Train those teams on framing problems and divergent and convergent thinking
- Create teams that are cross-functional to minimize dependencies
- Reflect on how teams are measured and what behavior this encourages
12. Reflect and adapt
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
How to apply Agile principle No. 12
The first mistake teams often make is running sprint retrospectives that are too predictable and too formal. Notice this agile principle makes no mention of a time frame; there’s no name or structure for this team reflection.
The second mistake (which often stems from the first) is a lack of accountability; too often, there is no follow-up or tracking of action items. I don’t believe every observation in a retrospective-like conversation needs to have an action item. However, when action items are defined, you should establish some accountability to ensure that progress is made.
How to apply this principle
- Check in regularly with your team and colleagues
- Track next steps when necessary
- Have fun and be genuine
What the 12 Agile principles are not
Now that you have seen and understand what all 12 Agile Manifesto principles are, let’s review what they are not.
The agile principles are not a methodology or part of a methodology. The principles aren’t really a framework, either. In the Agile world, frameworks are the more prescriptive sets of rules, systems, and processes to help teams put the agile principles into action.
The agile principles are statements that add more color to the higher-level values of the Agile Manifesto. They are the specific stances of professionals who value continuous learning and improvement in an increasingly unpredictable world.
Is the Agile Manifesto still relevant today?
I believe the Agile Manifesto has aged quite well, all things considered. It is still a set of values that offers a healthy challenge for tech and business professionals alike.
Not only does the Agile Manifesto remain helpful, but many other industries outside of software development have adopted it. Simply tweaking a few references to “software” has gone a long way toward helping marketing teams, human resources, and many others to deliver valuable outcomes more efficiently.
Despite dozens of Agile Manifesto alternatives, extensions, and calls for complete replacement, the general consensus is that the document has stood the test of time remarkably well. Arguments from critics are often misguided, unconvincing, or just not adding enough value to get widespread attention. There is so much content out there now, a new Agile Manifesto would need to be revolutionary to get traction.
Agile Manifesto TL;DR summary
To summarize the key takeaways from this Agile Manifesto guide:
- The preamble, which is the most overlooked part of the manifesto, encourages continually “uncovering better ways” and “helping others” along the way
- Value No. 1 is the most ahead of its time and places people, collaboration, inclusion, and relationships at the center of Agile. To paraphrase this value for modern software development: Processes and tools are valuable, but people and relationships are even more important
- Value No. 2 is the most controversial today because it espouses “working software over comprehensive documentation.” Modern paraphrase: Robust documentation is good, but actually delivering solutions is better
- Value No. 3 is the most misunderstood due to “contract negotiation” and vagueness around “customer.” Modern paraphrase: Commitments are good, but building the right thing is better
- Value No. 4 is the heart of Agile: “Responding to change over following a plan”
Featured image source: IconScout
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
