What Is the Agile Manifesto?
The Agile Manifesto is a document that was created by 17 developers while on a ski retreat at The Lodge at Snowbird ski resort in Utah between February 11th and February 13th, 2001.
Naming themselves “The Agile Alliance,” they agreed that the status quo of development wasn’t working. There was a growing need for a different approach from the current documentation-driven and cumbersome software development processes.
The document, formally called the Manifesto for Agile Software Development identifies four key values and 12 principles that the authors believe software developers should use to guide their work.
The document is housed on agilemanifesto.org where the developers say that the goal wasn’t anti-methodology, but rather, “to restore credibility to the word methodology.”
It’s important to point out that the Agile Manifesto wasn’t the beginning of the Agile Methodology. Before this, creators and other software developers had been applying various agile values and principles sporadically. The Manifesto made those ideas concrete that had been floating in the ether of software development but hadn’t yet been formalized.
Who signed the Agile Manifesto?
The creators and original signees of the Agile Manifesto, self-coined the Agile Alliance, are as follows:
- Kent Beck, who co-created eXtreme Programming (XP)
- Mike Beedle, co-author of Agile Software Development with Scrum
- Arie van Bennekum, owner of Integrated Agile
- Alistair Cockburn, IT strategist and creator of the Crystal Agile Methodology
- Ward Cunningham, inventor of wiki and first to coin term technical debt
- Martin Fowler, software practitioner, and partner at Thoughtworks
- James Grenning, author of Test-Driven Development
- Jim Highsmith, creator of Adaptive Software Development (ASD)
- Andrew Hunt, co-author of The Pragmatic Programmer
- Ron Jeffries, co-creator of eXtreme Programming (XP)
- Jon Kern, who still helps organizations with agile today
- Brian Marick, a computer scientist and author of several books on programming
- Robert C. Martin, also known as “Uncle Bob,” who consults via Clean Coding
- Steve Mellor, a computer scientist also credited with inventing Object-Oriented System Analysis (OOSA)
- Ken Schwaber, who co-created Scrum with Jeff Sutherland
- Jeff Sutherland, the inventor, and co-creator of Scrum
- Dave Thomas, programmer, and co-author of The Pragmatic Programmer
What Are the 4 Core Principles of Agile Methodology?
Value 1: Individuals and interactions over processes and tools
Before the manifesto, many software teams would focus on having the absolute best tools or processes to build out their software.
The manifesto says that while tools and processes are great, they’re not as important as the people behind them.
Simply put, your team and their ability to communicate effectively and efficiently is more valuable than the processes they follow or the tools they use.
This isn’t to say that tools aren’t important, but at the end of the day, they come second to team alignment.
Value 2: Working software over comprehensive documentation
Since the practice of software development came into being, developers would spend countless hours creating detailed documentation. Before they even started writing even a line of code!
Now, there is nothing explicitly wrong with documentation, the thought is that you should focus on providing your customers with working software before all else.
There are a few types of qualitative research that you can use before getting to a minimum viable product (MVP), but since agile is about speed, the best practice is to get a product working and then test it with potential customers.
Value 3: Customer Collaboration over contract negotiation
In the early days of software, contracts were king, queen, and the prince. A contract would basically be drawn up with your customer, who would then fill in what they wanted the finished product to do.
What ended up happening was a divide between what the contract said, what the product actually did, and then what the customer actually needed.
In hindsight, this disconnect was bound to happen because you’re essentially asking the customer to be the product owner. Of course that doesn’t work!
The Manifesto changed this thinking to a constant feedback loop, meaning customer collaboration begins early in the development process and happens frequently throughout.
It’s a constant collaboration between customers and product people to ensure the delivery of effective, useful solutions to customers.
Value 4: Responding to change over following a plan
Now, for my Product managers, imagine a world where you create a roadmap and then that roadmap never changes. That’s how it used to be!
Nothing in this world is static, so why, in a constantly changing world, would you have a static roadmap?
Needs and requirements are always changing and priorities are always shifting. Sooner than you can say roadmap, your static version will become outdated.
So, the suggestion by the agile alliance is that software teams ought to have the ability to pivot and change direction whenever they need to… or to put it simply, have a flexible roadmap.
What Are the 12 Principles of the Agile Manifesto?
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
In early iterations of traditional management methodologies, the customer only got to see the product after its completion when several tests and quality checks had been performed. This simultaneously kept the customers in the dark and also made it difficult for team members to change the product in any other way.
The goal of this principle, therefore, is to keep customers happy by continuously engaging them with a working version of the product.
Therefore, this can be understood as customers are happier when they receive working software at regular intervals, rather than waiting extended periods between releases.
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
In a world that’s constantly changing, nobody knows that a final product will look like.
Unfortunately, businesses don’t want surprises.
Even more, they don’t want to pay for something that isn’t relevant.
Welcoming change allows developers to pivote their product into something that satisfies the current and latest needs rather than those of last year.
Embrace the change, so says the manifesto.
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
I know what you’re thinking: this principle sounds a lot like principle one.
In a way, it is, but the focus of principle one is delivering software early,
This principle goes a little bit more into detail about what delivering continuously means.
The recommendation here is to deliver your newer version of your software within a short time scale, meaning smaller releases, meaning less bugs getting through.
On top of these, you will also receive more feedback from your clients. If you wait for feedback all at once, you’ll be swamped with improvements rather than incremental changes.
In the past, it was a release every couple months, but the manifesto helped it evolve to daily or weekly.
Principle 4: Business people and developers must work together daily throughout the project.
Developers and business people are often starkly divided and analysts are put between them to translate business language into developer language.
The manifesto says this creates an unnecessary bottleneck and developers and the business ought to interact with each other daily to create understanding and respect.
In the modern world, cross-functional teams work together closely on a daily basis. There is no reason to have a bottleneck, so says the manifesto.
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Getting to the point where your agile team is mature and responsible enough to product quality software requires a certain amount of trust and collaboration. This makes the alignment of the team play a key role.
It’s easier said then done, but with the right coaching, environment, tools, and motivated developers that are included in the decision making process, it is very possible.
Looping your team into the roadmapping and prioritization process goes a long way in making this a reality.
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Keep in mind this was written in 2001, and since then, technology has increased the number of ways in which we can communication.
Nothing is and never will be as good as face-to-face communication.
However, facetime, zoom, and any other kind of video conferencing software serves the purpose. Face-to-face isn’t so you can smell the other person’s coffee breath, but rather interpret a whole bunch of things based off of facial expressions that wouldn’t be readily apparent.
This is good enough, but even the manifesto couldn’t predict how far we would come in this regard.
Principle 7: Working software is the primary measure of progress.
Software products can take a long time to develop so it’s absolutely imperative to measure progress.
How do we measure progress? Working software.
Robust analysis, complete models, or spectacular mock-ups have little meaning if there is no software. If you do all of these, and don’t have a working product, than you have created 0 value for your customer.
Now, we go even further.
Anything that isn’t working software that hasn’t been shipped is inventory. And inventory is a cost, not a piece of income or value.
Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Pressure, also known as stress, isn’t necessarily a bad thing. Nothing will get done if there is no drive behind doing it. As long as it’s applied aptly and consistently without being the primary facet of the role, consistent, adequate production will take place.
In that same vein, Agile teams can handle intense periods of high paced work, but it should be balanced with periods of slow paced work.
If the organization is always stressing their teams, the rubber band will burst.
That’s why finding a consistent, adequate pressure is key.
Pay attention to the principle’s use of sponsors, developers, and users.
Developers can absolutely produce too many features for their average user. So with that being said, it’s always about keeping a balance of development and resources to make sure all parties are working harmoniously whilst no one is overwhelmed.
The principle can therefore be surmised as all stakeholders are able to keep pace with the development of which software is being used.
Principle 9: Continuous attention to technical excellence and good design enhances agility.
You’ll see a lot of businesses prefer time-to-market over good technical design, which is fair, as, you know, they’re a business.
Moreover, the end-user doesn’t care about technical excellence and doesn’t care about the income it generates for the business.
But here’s the Catch-22: if teams neglect a good technical design for too long, their speed AND time-to-market will slow down as well as their ability to adapt the product to the market.
The larger the product gets, the more invaluable this becomes. If you build a product on a base made of toothpicks, there is only so much you can add before it caves in.
A well designed product, meanwhile, will let you continuously add to it without impacting the integrity of what is.
Here’s a good graph by one of the original members of the agile alliance, Martin Fowler, that illustrates the point:
Principle 10: Simplicity– the art of maximizing the amount of work not done– is essential.
As more and more new technologies are developed to be added to the tech stack, simplicity because key to the agile development process.
You can do things like remove irrelevant procedures, automate manual work, or use existing libraries instead of writing your own, for instance. It all saves time and money to focus stakeholders on delivering more value.
Always allowing for change to a more simplistic approach is not only encouraged, but lauded.
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
You want your software development to be whirring like an engine, therefore, having self sufficient teams is integral.
Teams ought to go out of their way to do things like gather requirements from communication with the business, write quality software, and organize their work.
This leads to better software because developers own their work and care deeply about it.
Some still (incorrectly) view developers as factory-line workers that can be fed requirements, however, software development is work that requires so much more. The team needs autonomy to deliver quality.
Agile developers, in that same vein, should take ownership and responsibility for their output. It’s more than just writing code. So says the manifesto.
Principle 12: The team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Regularly, these self-organizing teams ought to take the time to look at the way they work and adjust as necessary.
No team is perfect.
However, a mature agile team can identify issues with respect for each other and then take the necessary action to improve them.
This principle will always matter as it is what makes individuals, teams, and the business successful by not just accepting the status-quo.
Always be improving. So says the manifesto.
The Agile Industrial Complex
The manifesto has permeated itself into all facets of business, even though it was created explicitly for business.
WIth that being said, terms like “faux agile” and “dark agile” have become synonymous with the monetization of agile education and consulting. It’s been coined “the agile industrial complex.”
This is because we believe that agile is a cultural value, and all teams, whether it’s sales and marketing or software development should be empowered to work as they best see fit. Without that cultural focus, the true core of the agile methodology is lost.
We practice what we preach.
Ron Jeffries, one of the originals of the agile alliance, addresses this aptly:
“I use the quoted word ‘Agile’ to refer to the many instances, approaches, and processes that use the word ‘agile’ to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto. I will sometimes refer to ‘Faux Agile’ for emphasis, or to ‘Dark Agile’, which I use to describe so-called ‘Agile’ approaches that have really gone bad. I might refer to ‘Manifesto Agile’ to mean the core ideas from the Manifesto, in which I still believe.”
Is the Agile Manifesto Still Relevant?
Short answer: Yes.
Agile always existed.
What the Agile manifesto did was codify a way of thinking that hadn’t yet been used for software development, which cannot be undersold.
Tanner Wortham, Agile Coach and Senior Technical Program Manager, put it succinctly:
“Until you can name something, you really don’t know what to do about it. I think that’s what the Manifesto did. It gave it a name. And they called it agile. I think it was something that was already occurring. But when they named it, they could start more easily identifying it.”