Agile Manifesto
What is the Agile Manifesto?
Definition of Agile Manifesto
The Agile Manifesto is a document that sets out the key values and principles behind the Agile philosophy and serves to help development teams work more efficiently and sustainably.
Known officially as ‘The Manifesto for Agile Software Development’, the manifesto detailing 4 Values and 12 Principles.
Acting as a proclamation, it is designed to improve software development methodologies, and directly responds to the inefficiency of traditional development processes. Namely, their reliance on weighty documentation and opportunity for oversight.
While the original document specifically set out to help software developers build business solutions in a faster and more efficient way, it has had a huge impact on the wider development industry and beyond.
Today, groups as diverse as PR and marketing departments, coders, restaurateurs, and even The Boy Scouts of America use the manifesto in one way or another, and its influence only continues to expand.
So, what are the core values and principles of the Agile Manifesto?
Let’s break it down...
The 4 agile values
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
The 12 agile principles:
The highest priority is to satisfy the customer through early, and continuous, delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
Clients and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to, and within a development team, is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development — the sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
History of the Agile Manifesto
Although various agile principles have been around since the 1970s, the manifesto itself — and the full definition of the agile philosophy — was created at the dawn of the new millennium.
In early 2001, a group of 17 developers held two meetings — the first in Oregon, the second in Snowbird, Utah — to discuss issues and solutions in software development, which is how the manifesto was firstborn.
Put simply, the manifesto was written as a response to major frustration with the traditional development processes of the 1990s.
The explosion of personal computing meant that product and software development had undergone significant changes, and developers at the meetings — and indeed, across the wider industry — felt that the status quo was no longer working.
The lag time between business needs and solutions being developed was an average of three years, and the standard processes at this point were unwieldy, unsatisfactory, and overburdened with documentation and oversight.
The 17 developers who met in Oregon and Utah named themselves ‘The Agile Alliance’, and proposed a new way of working based around a set of values and principles that would “restore credibility to the word ‘methodology’”.
The manifesto was designed to empower developers, speed up processes, and help encourage working practices that focus more directly on the user.
The values and principles allow teams to be adaptive, to respond quickly and effectively to change, and to be in a state of constant reimagination underpinned by frequent customer feedback.
Published in February 2001, the manifesto has since formed the basis of a vast array of frameworks, methodologies, and different ways of working.
Who is the Agile Alliance?
The original signatories to the Agile Manifesto were a group of 17 developers, scientists, programmers, and authors who came together to find a solution to the perceived ills of the software development industry.
Agile philosophy pre-dated the Agile Manifesto, and the group included a number of inventors and creators of earlier agile frameworks. Kent Back of extreme programming, Jim Highsmith of adaptive software development, and Jeff Sutherland of Scrum, to name a few.
The full list of signatories is:
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.
Is the Agile Manifesto still relevant today?
The beauty of the Agile Manifesto is that despite changes the industry has seen, despite the passage of time, and despite the fact that it has been applied to sectors and organizations far and beyond its original scope — the manifesto’s flexibility and adaptive nature mean that it continues to be relevant today.
Agile is a mentality — a philosophy — and the manifesto sets out principles and values, rather than prescribing certain processes. This means that plenty of developers work with an agile mindset without even realizing it. The manifesto merely formalizes how many successful teams have always worked.
The real problem with the manifesto today is not whether it is relevant, but how it is applied — or rather how it is applied incorrectly.
In part due to its flexibility, one of the biggest problems with agile is that some teams describe themselves as such without properly applying or understanding the underlying principles.
Plenty of ‘agile’ teams, for example, sometimes use the manifesto as an ‘excuse’ to abandon traditional development processes and to reject rigor, without ever really considering the fundamentals behind an agile mindset.
When used correctly, though, the manifesto remains as relevant today as it did when it was written, and can be a hugely valuable tool for developers, teams, and even entire organizations.
After more than 20 years...has the agile manifesto achieved its vision?
February 2021 marked the 20th anniversary of the Agile Manifesto. The world has changed dramatically since its introduction both in terms of society and the way we work. Despite this, the Agile Manifesto still holds up. While the concept isn’t new anymore, it still guides many of our practices and strategies. But has it achieved the vision like its creators hoped? Yes and no.
Some feel that we are far from achieving the vision laid out by the original Agile Manifesto.
This is especially true for enterprise-level businesses, which, as described by Brian Dawson, DevOps evangelist with CloudBees, is like a “tanker” being turned slowly and incrementally.
Unfortunately, many companies still treat “agile” as a buzzword. They will introduce agile to the office and expect everyone to jump on board but then do little to implement and maintain agile practices.
They try to make agile work around their existing processes rather than building new processes around agile principles. They see it as a medicine to heal the company’s problems when they’re just applying a bandaid and hoping for the best.
Enterprise-level businesses will also see agile as purely related to product development. They will only roll out Agile to those specific departments and hope it results in higher quality products and increased output. But, as those familiar with Agile already know, the Agile principles need to be embraced at an organizational level to benefit from its true value.
There’s a tendency to pigeonhole agile into rigid processes. Some see Agile as a simple process that you can immediately do and start calling the business Agile.
This leads to processes created for the sake of having processes which only serve to disconnect businesses and their workers. By viewing Agile as a rigid process, you lose almost all of the benefits of working with Agile.
Yet, at the same time, there’s a tendency to stray too far away from rigidity. Some see Agile as a free-for-all methodology that lets teams aimlessly go with the flow. While this can occasionally produce great results, fooling businesses into thinking their version of Agile is working, it simply leads to a lack of discipline within your teams. An Agile coach may seem like an unnecessary cost, but having one is essential to keep your team working hard while still embracing Agile practices.
Thankfully, start-ups are much better at adopting the values of the Agile Manifesto. Since they don’t already have established processes baked into the company culture, they can build their practices around the agile principles so that they are front and center during everything they do.
This is great news for agile fans, because today’s start-ups will grow to be tomorrow's enterprises.
So while we’re not quite there yet, we’re certainly on our way to achieving the vision of the Agile Manifesto.
Agile Comparison to other methodologies
Waterfall
Waterfall is a more traditional way of developing products and software. It breaks the development process down into sequential stages that feed into each other, flowing toward the project’s completion.
This methodology will typically include the creation of a document that lists requirements, designing the software architecture, designing the UX and UI, software development, prototype testing, and verification that the work meets the requirements.
Unlike Agile methodologies, Waterfall is a very linear process with little room for change during the process. This makes it a difficult framework to follow for teams that will deal with changing requirements in fast-paced environments.
Scrum
Agile and Scrum are often confused because they both use an iterative process with frequent communication and collaboration. However, Agile is a philosophy with a core set of principles, whereas Scrum is a type of Agile methodology that can be used to complete a project. Scrum also differs in the way you deliver. Scrum produces a deliverable at the end of short sprints, whereas Agile sees everything delivered at the end of a project.
While the two are used interchangeably, it’s important to remember that Scrum is Agile, but not all Agile workflows use Scrum.
Lean
Again, Lean and Agile are often confused with each other. This is because Lean has some similar principles to Agile, but the priorities differ. As the name suggests, Lean is about minimizing waste, managing processes, and delivering nothing but value. It tasks teams with identifying and building customer value using the value stream. Products and features are built to match customer demand, eliminating overproduction and waste.
Agile and Lean timelines are much different. Agile projects are broken down into short cycles with a deliverable at the end of each sprint. Lean projects will optimize process flow to limit the work-in-process and minimize the overall project timeline. However, there is no specified time frame for completion.
Kanban
Kanban is less about how you work and more about how you define, manage, and improve services for delivering knowledge work. Like Agile, Kanban allows for reprioritization during the project to reflect any change in requirements.
There are big differences between Kanban and Agile. Agile focuses on consistent communication and iterative development, whereas Kanban is not iterative and serves to improve the team’s processes. Kanban timelines are also much shorter than the already short timeframes of Agile, meaning teams must focus only on value.
General FAQ
Glossary categories
Experience the new way of doing product management
Experience the new way of doing product management