In this guide, we’ll examine each of the 12 Agile principles as outlined in the Agile Manifesto. We’ll break down what the authors meant and walk through steps to apply each principle in your daily work as a product manager.
The Agile Manifesto was written in 2001 by proponents of lightweight software development, which aimed to combat traditional project management processes. A few months later, the authors added a set of 12 Agile principles as an extension to the Manifesto.
The old ways favored heavy planning and documentation before development and little feedback from clients and the market. These key principles for the new era of agile development serve to elaborate on the Manifesto’s four key values.
Despite some criticism from various corners of the software development world, the Agile principles have left their mark. Today, they are still widely considered timeless and challenging to master.
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.
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.
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.
Red-teaming reveals how AI fails at scale. Learn to embed adversarial testing into your sprints before your product becomes a headline.
Cory Bishop talks about the role of human-centered design and empathy in Bubble’s no-code AI development product.
Learn how to reduce mobile friction, boost UX, and drive engagement with practical, data-driven strategies for product managers.
Jim Naylor shares he views documentation as a company’s IP and how his teams should use it as a source of truth.
Learn more →
