What Is the Agile Manifesto? Values, Principles, and Relevance Today

What Is an Agile Manifesto?

The Agile Manifesto is a document created by 17 developers on a ski retreat at The Lodge at Snowbird ski resort in Utah. Developers came up with the Agile Manifesto 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. 

Agile Manifesto has values and principles. The document formally called the manifesto for agile software development, identifies four fundamental values. Also, the 12 principles the authors believe software developers should use to guide their work. 

You can find the document on agilemanifesto.org. The developers say that the goal wasn’t anti-methodology. But instead “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 sporadically applied various agile values and principles. 

The software development manifesto formalized ideas circulating within the industry but still lacked formal definition.

Who Are the Signers of Agile Manifesto? 

The creators and original signers 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,” 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 Values of Agile Manifesto?

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 crucial as those behind them. 

Your team and their ability to communicate effectively and efficiently is more valuable than the processes they follow or their tools. 

The principle does not imply that tools aren’t essential, but 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

Let us understand the third value of the Agile Manifesto values. In the early days of software, contracts were king, queen, and prince. A contract would be drawn up with your customer, filling in what they wanted the finished product to do. 

What ended up happening was a divide between what the contract said, what the product did, and what the customer needed. 

This disconnect was bound to happen because you essentially asked the customer to be the product owner in hindsight. Of course, that doesn’t work.

The Agile Manifesto changed this thinking to a constant feedback loop. Meaning, that customer collaboration begins early in the development process and frequently happens throughout. 

It’s a constant collaboration between customers and product people to ensure the delivery of effective, valuable solutions to customers. 

Value 4: Responding To Change Over Following a Plan

For my product managers, imagine a world where you create a roadmap that never changes. That’s how it used to be.

Nothing in this world is static, so why would you have a static roadmap in a constantly changing world?

Needs and requirements are constantly 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 needed. 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. You can only consider it done after running multiple tests and quality checks. Such a process simultaneously kept the customers in the dark and made it difficult for team members to change the product in any other way. 

Therefore, this principle aims to keep customers happy by continuously engaging them with a working version of the product.

Thus, customers are happier when receiving 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. 

Nobody knows what a final product will look like in a constantly changing world.

Unfortunately, businesses don’t want surprises. 

They don’t want to pay for something that isn’t relevant. 

Welcoming change allows developers to pivot their product into something that satisfies the current and latest needs rather than last year. 

Embrace the change, so says the manifesto. 

Principle 3: Deliver Working Software Frequently, From a Couple of Weeks To Several Months, With a Preference for the Shorter Timescale.

We know what you’re thinking: this principle sounds like principle one. 

In a way, it is, but the focus of principle one is delivering software early,

This principle goes a little 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. It implies more minor bugs getting through. 

On top of these, you will also receive more feedback from your clients. If you wait for feedback all at once, improvements rather than incremental changes will overwhelm you. 

In the past, the release was once every few 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. Analysts are put between them to translate business language into developer language. 

The manifesto says this creates an unnecessary bottleneck. Thus, developers and businesses should interact daily to generate understanding and respect. 

In the modern world, cross-functional teams work together closely daily. 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 for product quality software requires trust and collaboration. Hence, making the team’s alignment plays a key role. 

It’s easier said than done. But with the right coaching, environment, tools, and motivated developers included in the decision-making process, it becomes easier. 

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 is from 2001. Since then, technology has increased the number of ways we can communicate. 

Nothing is and never will be as good as face-to-face communication. 

However, facetime, zoom, and other video conferencing software serve the purpose. Face-to-face isn’t so you can smell the other person’s coffee breath, but rather interpret many things based on facial expressions that wouldn’t be readily apparent. 

Though this is good enough, 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 measuring progress is imperative. 

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, you have created 0 value for your customer.

Now, we go even further. 

Inventory is anything that isn’t working software and not shipped. 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 gets done if there is no drive behind doing it. Consistent, adequate production will occur as long as it’s applied aptly and consistently without being the primary facet of the role. 

In that same vein, Agile teams can handle intense periods of high-paced work. But it would help if you balanced it with periods of slow-paced work. 

If the organization is always stressing their teams, the rubber band will burst.

That’s why finding consistent, adequate pressure is critical. 

Pay attention to the principle’s use of sponsors, developers, and users.

Developers can produce too many features for their average user. It’s always about balancing development and resources to ensure all parties work harmoniously while no one is overwhelmed.

Therefore, the principle infers that all stakeholders can keep pace with the development of software usage. 

Principle 9: Continuous Attention to Technical Excellence and Good Design Enhances Agility. 

You’ll see many businesses prefer time-to-market over good technical design. This preference is fair, as, you know, they’re a business. 

Moreover, the end-user doesn’t care about technical excellence and its income 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. Additionally, their ability to adapt the product to the market also gets affected. 

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. 

Meanwhile, a well-designed product will let you continuously add to it without impacting the integrity of what it is.

Principle 10: Simplicity– The Art of Maximizing the Amount of Work Not Done– Is Essential. 

As more and more new technologies are developed and added to the tech stack, simplicity becomes key to agile development. 

You can remove irrelevant procedures, automate manual work, or use existing libraries instead of writing your own. 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 gather requirements from communication with the business, write quality software, and organize their work. 

Such dedication 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 should take ownership and responsibility for their output in that same vein. 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. 

These self-organizing teams should regularly 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. Then, they take the necessary action to improve the situation. 

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. 

What Are the Examples of Agile Manifesto?

Philips follows Agile principles. Following modifications to its management system, they hired multiple Agile coaches. The goal was to implement Scrum principles and split teams into smaller units. Teams were ready to respond to problems faster due to these improvements.

JP Morgan Chase is yet another firm that requires no explanation. As a robust IT strategy component a few decades back, this banking company altered its business procedures. The intention was to help boost product innovation while also reducing training costs. Agile methodologies were an essential aspect of the project.

The Agile Industrial Complex

The manifesto has permeated itself into all facets of the business even though it was created explicitly for business. 

Terms like “faux agile” and “dark agile” have become synonymous with the monetization of agile education and consulting. It’s coined “the agile industrial complex.” 

At Chisel, we try to avoid this trap, so that’s why we’ve made our agile tools like a Kanban board, free forever. Chisel is among the best product management software you can find that comes with various tools a PM needs in day-to-day task management.

We believe that agile is a cultural value, and all teams, whether sales and marketing or software development, should be empowered to work as they best see fit. Without that cultural focus, the actual core of the agile methodology gets 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 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 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. 

The Agile Manifesto codified a way of thinking wasn’t used for software development.

Tanner Wortham, the agile coach, and senior technical program manager, put it succinctly: 

“Until you can name something, you don’t know what to do. 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.”