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:
The four values of the Agile Manifesto are:
The 12 principles of agile software development as outlined in the Agile Manifesto are as follows:
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.
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.
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.
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.
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.
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.
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 values as stipulated in the Agile Manifesto are as follows:
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:
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.
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.
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.
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.
To review and for quick reference, the 12 Agile Manifesto principles (in shorthand) are as follows:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
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.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
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.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
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.
Business people and developers must work together daily throughout the project.
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.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
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.
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:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
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.
Working software is the primary measure of progress.
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?
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
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.
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.
Continuous attention to technical excellence and good design enhances agility.
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.”
Simplicity – the art of maximizing the amount of work not done – is essential.
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.
The best architectures, requirements, and designs emerge from self-organizing teams.
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.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
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.
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.
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.
To summarize the key takeaways from this Agile Manifesto guide:
Featured image source: IconScout
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.
It’s important to distinguish between these roles and create an infrastructure where they come together to build useful products.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
Learn more →
