In the 1990s, as information technology boomed, the software industry also witnessed remarkable advancements. However, software development teams at the time began to grow weary and increasingly constrained by traditional development methodologies - particularly the "Waterfall" model. Under the Waterfall approach, all project requirements are defined upfront, followed by the creation of a comprehensive design, with the entire software product then built based on a fixed plan established at the start. This rigid, linear process often resulted in heavy, inflexible projects that struggled to adapt to change or evolving customer needs.

In 2001, a group of seventeen individuals (including the founders of Scrum and XP) gathered for a special meeting at the Snowbird ski resort on the outskirts of Salt Lake City, Utah, USA. While none of them knew exactly what conclusions would emerge from the meeting, they all shared a strong belief that traditional software development approaches were too heavy and burdensome, and that a new, lighter-weight way of building software was needed. They also believed that the emerging methodologies had common values and principles. They also believed that . It didn’t take long for the group to reach consensus on four fundamental values - shared elements across these new approaches. These “4 values” became known as the Agile Manifesto.

The Agile Manifesto

Agile is often used in software development, but its principles can be applied across a wide range of industries. For that reason, the term software in the Agile context can often be interpreted more broadly to include systems, products, or other deliverables in different domains.

The question is, why is there no consensus on the best method to follow? Why stop at just "4 values"?

One of the fundamental truths in software engineering is that there is no one-size-fits-all solution for building software. The Agile Manifesto only presents values for project development teams to follow in order to achieve an Agile mindset. When individuals adopt the Agile mindset in their thinking and daily work, Agile will be truly helpful for improving the development of software/systems/products.

As we can see in the image above, the Agile Manifesto consists of 4 statements presented in the “X over Y” format, showing the 4 values of Agile. Let us explore these 4 values in more detail.

Individuals and interactions over processes and tools

Agile teams still acknowledge that processes and tools play an important role. Some of the tools and processes commonly used by Agile teams include daily standups, user stories, task boards, burndown charts, refactoring, retrospectives, and more (which we will explore in upcoming articles). These tools are truly effective when they are properly understood and applied. However, Agile teams place greater value on individuals and interactions over processes and tools, because people are at the heart of every challenge and every solution.

A tool or process may be effective for one team but can become a serious issue for another if the team does not perceive it as adding value to their work. Therefore, when introducing a new tool or process, it is essential for the facilitator or implementer to understand the perspectives of team members. It is also important to ensure that any tool or process adopted enhances collaboration - both within the team and between the team and its stakeholders.

Working software over comprehensive documentation

What does "Working software" really mean? How do we know if our software, system, or product actually works? This may seem like an easy question, but it is not. In traditional Waterfall projects, detailed documentation and specifications are created upfront to clearly define what the team will deliver. These documents are reviewed and approved by customers and stakeholders before the team begins development, strictly following the predefined plan. However, even the most professional teams have experienced painful meetings - where the team enthusiastically presents what they have built, while users or customers point out that key features are missing or that the product doesn’t work as expected. Such meetings often end in heated arguments. Usually, the team insists: “That’s not a bug—it’s just a feature that wasn’t documented, so we weren’t responsible for implementing it.”

Many teams try to solve these problems by preparing very detailed requirement documents and meticulous plans. However, in practice, this often makes things worse - not better. The reason is simple: everyone might be looking at the same requirements document or plan, but each person may interpret it differently. The best - and sometimes the only - way to know whether software/product truly works is to let the customer or user actually use it. If they can use the software/product to do what they want to do, then the software/product is usable - Working software / Working product. Agile teams still value the importance of using requirement documents and comprehensive plans. However, delivering software/products that meet customers’ and users’ needs is what matters most.

Customer collaboration over contract negotiation

It’s important to note that the term "contract" in this context doesn’t refer to a legal document. When Agile teams talk about "contract negotiation", they mean the attitude, mindset, and behavior people have towards customers or members of other teams. When team members adopt a “contract negotiation” mindset, they tend to believe that a formal agreement must be in place before any work begins. Many companies encourage this mindset, requiring members to clearly commit and agree on what they can deliver and by when (usually documented formally and subject to strict change control processes). “Contract negotiation” should be used in cases where customers are unwilling or unable to collaborate.

Agile teams are always aware that changes is inevitable in any project, and that we never have complete or perfect information at the start of a project. Instead of trying to finalize exactly what will be done at the beginning, Agile encourages close collaboration with users and customers to achieve the best possible outcomes (understanding their needs, updating information, and so forth as early as possible).

Responding to change over following a plan

Some project managers say, “Plan the work, work the plan”. Agile teams agree that planning is extremely important. However, strictly following a fixed plan can lead to significant issues. In traditional Waterfall projects, change is often viewed as a deviation from the plan, something to be minimized or avoided. These projects typically involve rigid and time-consuming change control processes, treating change as an exception rather than the norm.

The issue with planning in this way is that it is created in detail at the beginning of the project, when the team has very limited information about the product to be developed. Therefore, Agile teams recognize that plans will always change, and they frequently use methods and tools to identify changes and respond appropriately. One common tool Agile teams use is the Daily Standup Meeting, where team members can review the plan daily and coordinate together to respond to changes, allowing the project plan to be updated as early as possible.

When Agile teams value responding to change over following a plan, it does not mean they do not create specific plans - in fact, quite the opposite! Teams fully appreciate adhering to plans, it’s just that responding to change is valued more highly.

Summary

There is no perfect formula for building software or products. Some teams achieve great success and see significant improvements after adopting Agile, while others encounter challenges/issues. The biggest difference often lies in the mindset of the team members - whether they have an Agile mindset or not. So, what will you do to achieve these excellent results for your team? How can you make sure your team has the right mindset about Agile? That is why understanding the Agile Manifesto is essential. When you and your team understand the values and principles of Agile, your projects will become much more effective.

Knowledge compiled by Trainer Nguyen Hai Ha (PMP^®, PMI-ATP Instructor)

References: Head First Agile

See more

PMI-ACP Gaps

What is a Product Roadmap

Story Map - A key planning tool in Agile projects

Tracking Agile Project Progress with Burn-down and Burn-up Charts

Velocity - A tool to measure Agile team delivery rate