top of page

How the 12 Principles in the Agile Manifesto work in real life

Agile is an umbrella term encompassing a variety of frameworks and approaches to value delivery in complex environments. The word agile came into widespread use following the creation of the Agile Manifesto in 2001. That year, a group of 17 software practitioners looking for a better way to deliver software settled on the the term agile to refer to their more rational, human approach to complex work. Agile, in this context, is now a widely used term, and the Agile Manifesto has given rise to a plethora of new approaches since its creation, many of which claim the manifesto as their impetus and driving force—including Scrum.

The Scrum framework comes with its own guardrails and values, but it is worth taking a moment to consider the bulwark upon which Scrum is founded by examining the principles and values of the Agile Manifesto. The Agile Manifesto includes four values and 12 principles that describe a better way to approach complex work. Below, we will discuss each of the 12 principles and what they mean in the real world.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The image below is a famous example from Henrik Knilberg demonstrating an agile approach to product delivery and comparing it with more traditional methods.

The first principle included in the Agile Manifesto starts with “Our highest goal is to satisfy the customer….” This statement reflects what we all learned after running our first lemonade stand: to stay in business, we need to keep the customer happy. But it doesn’t stop there. The agile principles take this a step further and assert that the way to keep the customer happy is “through early and continuous delivery of valuable software.” In other words, the best way to keep the customer happy is to deliver valuable products to the customer frequently. After all, the only thing better than a great product is a great product that gets better often.

Unlike waterfall or other traditional project management approaches, agilists deliver early and continuously. We are not producing software once in one large delivery. Instead, we're delivering it frequently—or iteratively. Further, our customers must find what we deliver usable and valuable. It's an incremental approach. Rather than envisioning the end state of a product and working on that step-by-step, agile teams continuously ask themselves, what is the most valuable thing to do next?

The illustration above shows how this might look. The waterfall team envisions only the final product and delivers it in silos by working on systems that will be part of the final delivery, such as the tires, the frame and finally, the car. The agilists below them focus on the goal, which is transportation. In their first delivery, they manage to deliver a skateboard. In their second delivery, a skateboard with handles. Next, they produce a bicycle, then a motorcycle, and, finally, a car. Each delivery is usable, and each builds upon the previous work. These two scenarios show the difference between thinking only about the end state versus delivering value incrementally.

But isn’t that wasteful? Surprisingly, in the real world, incremental delivery is not wasteful. In fact, it eliminates waste because stakeholders and customers provide frequent feedback about whether what the team delivered was useful or whether the team should change direction. This regular feedback loop means that teams are less likely to spend a lot of time on features that are not useful to the customer.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The Agile Manifesto’s second principle speaks to a different approach to requirements. Traditional methods aim to reduce the amount of change while product development is in flight. Agile does just the opposite. Instead of focusing on reducing variation and changes to the original requirements, Agile frameworks welcome change. Delivering value in smaller, usable increments makes this possible. Agile teams learn something from the customer after each delivery, and because it's a smaller increment of work, it's possible to introduce new requirements.

Why do Agile teams welcome change? Teams use an agile framework in complex environments, where more is unknown than known. In that context, does it make sense for the team to plan everything at the start, when they know less, or does it make sense to replan regularly as they learn more?

The benefit of welcoming change means that agile teams are able to respond to changing circumstances as more information becomes known over time.

3. Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

All agile frameworks rely upon the principle of delivering working software frequently, but this principle takes it a step further. Teams must deliver working software; not just a cog in the machine, so to speak.

Consider the image below. The left-hand side of the image represents the traditional way of delivering value to the customer, which is a large deliverable provided after everything envisioned in the final product is complete. Contrast this with the right-hand side of the image, which shows an iterative (frequent), incremental (Done) approach for delivering value. Each piece of what is delivered is usable, but it’s a smaller piece of the bigger puzzle.

In Scrum, teams determine the frequency of value delivery by the length of the Sprint. The purpose of each Sprint is to deliver a Done, usable increment of work at least once per Sprint. The Product Owner then determines when to release the functionality to the customer. The Sprint length should be just long enough to allow the Developers to deliver a usable increment of product, and no longer, with a preference towards the shorter timescale.

4. Business people and developers must work together daily throughout the project.

To me, this principle generates the most noticeable changes in the day-to-day experience of an agile team compared to a waterfall or traditional team. Using a traditional approach, the delivery team often goes through a long, intense requirements phase where they frequently meet with the business stakeholders. After they complete the requirements phase, the delivery team disappears to build whatever they understand the stakeholders specified.

Agile is different. Business stakeholders meet regularly with the agile team at a lower level of engagement. In Scrum, this engagement may take place in refinement meetings or at the Sprint Review. In other agile frameworks, this engagement may take the form of replenishment meetings. Regardless, engagement, and therefore visibility, is continuous in an agile environment.

In the image above dashed lines represent a waterfall or traditional approach. The blue lines represent Scrum, which is the most popular agile framework. By engaging with stakeholders more frequently, agile teams provide greater visibility into product delivery. Whereas traditional teams rely upon infrequent progress or status reports to provide visibility, Scrum teams rely upon frequent inspection of Done, usable work at the Sprint Review.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Leaders who work with agile teams focus on ensuring that the teams have the support (tools, access, resources) and environment (culture, people, external processes) they need, and then trust them to get the job done. This principle can scare some leaders who have a more command-and-control management style. They wonder how they'll know if their team is succeeding and focusing on the right things. My response to these concerns is to focus on the team’s outcomes. Are they delivering working product frequently? Are they making progress towards their goals? Those are the metrics that warrant attention. It is a necessary shift in perspective and mindset, and it is one that leaders as well as agile teams need to make to achieve the best results. To learn more about how to support agile teams, leaders should consider attending the Professional Agile Leadership - Essential class.

Successful agile leaders enable teams to deliver value by providing them with the tools that they need to be successful, providing guidance when needed, embracing servant leadership and focusing on outcomes.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

With the greater adoption of Zoom and other meeting platforms, the words face-to-face have taken on a slightly different meaning lately, but the idea behind this principle remains. The best way to convey information is to have a real-time conversation rather than a back-and-forth via email or messaging app. For agile teams, this may mean that those who deliver the work speak directly to those using the work. Or it could mean that those who deliver the work collaborate amongst themselves to solve their problems. Each agile team determines how best to live this principle according to their unique situation. What matters is that collaboration is critical for all Agile teams.

The best way to collaborate is to have a conversation.

7. Working software is the primary measure of progress.

This is the third time that the word software has shown up in one of the principles of the Agile Manifesto. The use of the word reflects the fact that agile “grew up” in software development, meaning that many of those who originally participated in the creation of the Agile Manifesto were in the software field. Today, agile frameworks are used in venues as diverse as human resources, marketing and defense.