In 2001, 17 software professionals gathered in Snowbird and created the Agile Manifesto. Four values, twelve principles, and one powerful idea: in software development, you cannot predict everything upfront. You need to learn, adapt, and keep moving forward.
So, what exactly is Agile?
Agile is not a single methodology. It is an approach built around a set of values and principles, designed for environments where needs and constraints are constantly evolving. It favors short feedback loops, collaboration, value delivery, and adaptation over rigidly following an initial plan.
Originally developed for software development, Agile has since expanded well beyond its roots. Today, its principles can be found in marketing, HR, manufacturing, and across both hardware and software projects.
You don’t know everything at the start of a project
At the beginning of a software project, some decisions inevitably rely on assumptions: Which needs are most important? Which solution will work? How will users respond?
Some answers can only emerge once the product is built and used. Requirements evolve, technical constraints change, and priorities shift.
The problem isn’t planning. The problem is assuming that the initial plan will remain relevant until the very end.
A plan provides direction, but it needs to evolve as the team learns. That’s why Agile favors short cycles: build something, gather feedback, and adjust what comes next.
Plan → Build → Learn → Adapt.
The goal isn’t to eliminate uncertainty. It’s to reduce the risk of making too many decisions before you have enough information to make them well.
This is the reality that led to the creation of the Agile Manifesto.
The Agile Manifest
This shared realization gave rise to the Agile Manifesto in February 2001. It is not a prescriptive methodology with a fixed set of steps to follow. It is a statement of values and principles designed to guide decisions rather than dictate them.
The 4 values of the Agile Manifesto
The four values are often oversimplified or misunderstood. The Manifesto does not say that the elements on the right processes, documentation, contracts, and plans are useless. It says that when there is a choice, the elements on the left are valued more highly.
Source: https://agilealliance.org/
Individuals and interactions over processes and tools
What does this mean in practice? Collaboration, communication, collective intelligence, and empowered teams.
What good is an excellent process if the people using it cannot collaborate effectively?
Working software over comprehensive documentation
The value of a product lies in its ability to actually work, not simply in the amount of documentation produced around it. What matters is real-world validation through use not documentation created simply to “tick a box.”
An important nuance: Agile does not mean no documentation. It means useful documentation, created at the right time and for the right purpose.
Customer collaboration over contract negotiation
Regular feedback, continuous user involvement, the ability to evolve requirements, and ongoing validation rather than a single validation point at the end of a contract.
Responding to change over following a plan
Arguably the most fundamental of the four values. A plan is a hypothesis, not a promise. Information changes throughout a project, and change is not necessarily a problem it can create value.
Adapting your direction does not mean working without a plan or a clear objective.
Agile does not ask you to choose between planning and improvisation. It encourages you to plan while recognizing that reality may teach you something new.
The 12 Agile principles: the ideas behind the Manifesto
The 12 principles that accompany the Agile Manifesto are not a checklist of rules to apply one by one. They provide practical guidance on how to put the four values into action every day.
Rather than looking at each principle individually, they can be grouped around a few key ideas: customer satisfaction, frequent delivery, collaboration, and responding to change.
Put customer value first
Customer satisfaction comes first, supported by the early and continuous delivery of valuable software.
This means welcoming changing requirements, even late in the project, rather than treating them as disruptions to be avoided.
Collaborate to build better
The principles emphasize:
- Close, day-to-day collaboration between business stakeholders and developers
- Direct conversation as the most effective form of communication
- Trusting motivated individuals to get the work done
Measure progress through working software
“Working software” is the primary measure of progress.
Not the percentage of tasks completed on a project plan. Not the number of specification pages written. What matters is what actually works and can be demonstrated.
Maintain a sustainable pace and focus on quality
Agile processes promote a sustainable pace of development one that teams can maintain indefinitely.
Continuous attention to technical excellence and good design strengthens agility itself. Conversely, accumulating technical debt in the name of speed will eventually slow the team down.
Continuously improve
At regular intervals, the team reflects on how to become more effective and adjusts its way of working accordingly.
This is the spirit of retrospectives:
- Observe
- Learn
- Experiment
- Improve
All without waiting until the end of the project to question how things are being done.
Agile, Scrum, Kanban: what’s the difference?
It is common to confuse Agile with Scrum, or to assume that being Agile means using sticky notes on a Kanban board.
In reality, Agile refers to the values and principles we’ve just explored.
Scrum is a framework that puts those principles into practice through defined roles (Product Owner, Scrum Master), artifacts (Product Backlog), and short development cycles called Sprints.
Kanban, on the other hand, focuses on visualizing work and optimizing workflow, without requiring fixed iterations.
You can absolutely be Agile without using Scrum. Kanban is one concrete example, as are other approaches that embrace the same values without following the Scrum framework.
Why is Agile still relevant 25 years later?
Because uncertainty hasn’t gone away
In 2001, the 17 signatories of the Agile Manifesto were responding to a specific problem: rigid plans rarely survive contact with the reality of software projects.
That problem hasn’t disappeared. If anything, it has become more complex.
Organizations now have to manage more dependencies, more stakeholders, and more interconnected technologies than they did in 2001. Uncertainty is not a problem that technology has solved. It is part of the very nature of software development.
Because requirements evolve
A requirement expressed when a project starts is rarely exactly what matters six months later.
Real-world usage reveals new insights, business priorities shift, and competitors evolve. Trying to lock requirements down from day one ignores the fact that the requirements themselves are assumptions that need to be refined.
Because feedback remains essential
This is where the build → measure → learn → adapt cycle really comes into its own.
Without regular feedback, a team can spend a long time moving in the wrong direction without realizing it. Often, the problem only becomes visible at delivery when making changes is significantly more costly.
Because software is never truly “finished”
A software product that has been released is not necessarily a finished product:
- New features are requested
- Bugs emerge
- Security vulnerabilities need to be addressed
- Performance needs to keep pace with growing demand
- Regulations evolve
- User expectations change
Software continues to evolve after it goes live. Agile was designed precisely for this reality.
Because teams remain at the heart of value creation
No tool or process can replace a team that understands the problem it is solving and can quickly adjust its direction.
Agile has not remained relevant because it is a new idea.
It remains relevant because the problem it addresses building something useful in a constantly changing environment is still very much with us.
Putting Agile principles into practice today
In practical terms, applying these principles today comes down to a few simple habits:
- Start with the problem you need to solve rather than choosing a methodology first
- Make work in progress visible so everyone understands where the project stands
- Shorten feedback loops so you can learn earlier
- Prioritize based on the value being created rather than the order in which requests arrive
- Deliver regularly rather than waiting until the end of the project
- Measure to learn, not simply to track what has been completed
Agile in regulated environments
A common objection is that Agile and compliance are incompatible in environments with demanding compliance, security, or audit requirements.
Agile does not mean doing away with documentation. In practice, traceability can be continuous: requirements, tests, and validation activities can be documented throughout the development lifecycle rather than reconstructed at the end of a project.
Tools obviously do not replace these principles. But they can help teams put them into practice by connecting requirements, development, testing, and delivery within a single lifecycle.
That’s precisely where an ALM platform like Tuleap can help.
FAQ
What is Agile?
Agile is an approach to software development based on a set of values and principles including collaboration, frequent delivery, and responding to change rather than a single methodology.
Is Tuleap an Agile tool?
Tuleap is an ALM platform that supports Agile practices such as Scrum and Kanban across the entire development lifecycle, from requirements and code to testing, delivery, and traceability.
What is the difference between Agile and Scrum?
Agile is a set of values and principles. Scrum is a framework for putting those principles into practice through defined roles (Product Owner, Scrum Master), artifacts (Product Backlog), and Sprints. Learn more →
Is Agile still relevant 25 years later?
Yes. Requirements continue to evolve, uncertainty remains a fundamental part of software development, and software continues to change after it goes live. The conditions that gave rise to Agile in 2001 are still very much present today.
