Agile Manifesto

The Agile Manifesto is the main document that states the values and principles of the Agile methodology. Learn about the Agile Manifesto, its history, authors, values, and principles, as well as how to apply the Manifesto to software development.

Agile is a project management methodology that is characterized by short development cycles, close collaboration within the team, and between stakeholders and developers, adoption of change, and continuous improvement. Agile has been successfully applied to numerous projects over the last 20 years, and now we will look closely at the origin of this methodology.

What is the Agile Manifesto?

The Agile Manifesto is the main document that states the values and principles of the Agile methodology and guides teams on how to succeed in their adoption of the new philosophy.

What is the history of Agile?

For a moment, let’s go back to the 1990s. Business requirements were getting more and more sophisticated. The needs of customers and businesses were changing faster than developers could finish projects. Traditional approaches to software development led to a considerable time lag between spotting the market niche and finally releasing a product. That’s why many projects were simply canceled because there was no sense in finishing them. It was clear that the Waterfall model and other traditional approaches were not enough to deal with the growing pace of changes in the software development world.

So, 2000-2001 became a remarkable period when 17 experts gathered to create and formally write the Agile Manifesto and the Twelve Principles. The meetings happened at a resort in Oregon and a Snowbird ski resort in Utah.

Those experts agreed that the key problem was a too precise focus on planning and documenting, which left practically no room for thinking about customers and actually satisfying them. The Agile Manifesto was just 68 words long and had only 12 principles, yet it changed the future of many teams and companies.

Who were those 17 heroes?

The Agile Manifesto authors were specialists in software development, CEOs, directors of R&D, experienced programmers and consultants, founders, and owners of software development companies with a strong belief that people were at the heart of a successful project.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham James Grenning

Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Martin Fowler

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

The Manifesto for Agile Software Development

So, what does the Agile Manifesto say? The document consists of 4 key values and 12 principles. The Agile Manifesto’s purpose is to popularize a new approach to software development, the approach that regards software quality and customer satisfaction as a priority. The Manifesto says how to become a company that responds to changes in the market and customer requirements and still develops powerful software.

The 4 Values that matter

The Agile Manifesto proclaims four main 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.

#1. Individuals and interactions over processes and tools

Before the Agile Manifesto, companies focused a lot on finding the right tools and building proper processes. The Agile methodology suggests that gathering a decent team is more important than polishing processes. Even the most efficient processes and tools will be useless if individuals don’t work as a team, can’t or don’t want to communicate to solve problems.

#2. Working software over comprehensive documentation

Traditional approaches demanded creating detailed documentation and hence spending a lot of time on it even before you could start writing code. Though Agile is more about developing software, documentation is not excluded of course. Delivering the software to the client, getting feedback, and improving the product are the priorities for Agile developers. Documentation is secondary and boils down to the minimum that the team needs. In Agile, user stories are detailed just enough for developers to start building a new feature.

#3. Customer collaboration over contract negotiation

Traditional approaches to development implied that the project manager and the customer discussed the requirements for the project in detail before the team started to develop anything. If the Agile methodology is applied, the customer can be engaged throughout the development process. Such non-stop collaboration allows the team to deliver the product exactly the way the customer wants it. Periodic demos can happen along with the day-to-day participation of the customer in meetings and calls.

#4. Responding to change over following a plan

Traditional approaches to software development see change as a thing that can be avoided if everything is thoroughly planned. Detailed plans implied delivering project parts in a specified order. In Agile, changes are not regarded as expenses, they are necessary improvements that bring value. Short iterations and shifting of priorities from iteration to iteration are welcomed and bring in flexibility. An Agile team can adjust the process to the changing situation.

Twelve Principles of Agile Software Development

The Twelve Principles describe the path that leads from a traditional development methodology to the corporate culture welcoming changes and focusing on the customer. The Agile Manifesto Principles show how to align the development, business needs, and the culture of change.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Customers want to get the software they imagined as soon as possible. When they can see and try the working app regularly, customers are more satisfied with the results of cooperation.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. The team can accommodate changes and finds ways to deliver results without delays even when requirements change.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Agile teams split work scope into sprints or iterations and show the customer parts of a working software regularly.
4. Business people and developers must work together daily throughout the project. Stakeholders know the tool that they want to get from a business perspective, developers think about technical efficiency. Working in tandem, customers and developers can build software that satisfies both technical and business requirements.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Motivated teams will do their best and cooperate to bring the project to success.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. A single location and the possibility to discuss project matters and exchange expert tips help teams to avoid time lags and misunderstanding of information.
7. Working software is the primary measure of progress. Only the result as a working tool is considered a success, and not the processes or fulfillment of initial requirements.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Teams find the pace at which they can develop the needed parts of the software and repeat the results from iteration to iteration.
9. Continuous attention to technical excellence and good design enhances agility. The team should have enough skills and accurately build parts of software in every iteration. This way they will be able to keep the right pace and improve the software from iteration to iteration.
10. Simplicity — the art of maximizing the amount of work not done — is essential. This principle is about building the functionality that is really needed and avoiding excessive efforts.
11. The best architectures, requirements, and designs emerge from self-organizing teams. If all members have enough competencies and work as a team, cooperate and exchange ideas, they can achieve much better results than by simply following instructions.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Non-stop self-improvement and review of processes help team members to spot weaknesses and find ways to overcome them.

Benefits of Agile project management

What do you actually get when you apply Agile methodology to your development processes?

• Higher product quality
• More predictable project results
• More satisfied customers
• More cooperation in your team
• More control over the progress of work
• Better visibility of efforts and progress
• Team structure adequate for the project
• Fewer development risks

Popular Agile frameworks

There are several Agile frameworks, Scrum, Kanban, Extreme Programming, Crystal, Lean, and others. So, what is a framework? An Agile framework is an approach to software development that is still based on the Agile philosophy.

Regardless of the framework used, Agile projects consist of 5 common steps:

1. Project initiation
2. Project planning
3. Project execution
4. Project monitoring and control
5. Project closure

Different Agile frameworks treat these steps in their specific ways. Though Agile is more about people than processes, teams can use frameworks as a starting point. You can change some parts of frameworks to adjust them to your processes.

Let’s list the most popular frameworks:

• Scrum
• Kanban
• Lean (LN)
• Extreme Programming (XP)
• Dynamic Systems Development Model (DSDM)
• Feature-driven development (FDD)
• Crystal
• Adaptive software development (ASD)
• Agile Unified Process (AUP)
• Disciplined Agile delivery
• Scaled Agile Framework
• Scrumban
• RAD (Rapid Application Development)

Is the Agile Manifesto still relevant?

Customers, coaches, and Agile enthusiasts state that Agile is as fresh and effective as it used to be in the beginning. Tanner Wortham, Director of Technical Program Management at Salesforce and a former Agile Coach at LinkedIn, admits that he often quotes the Manifesto at work. He started to use it even before Agile was officially called this way.

Can Agile become outdated? 

It’s very doubtful. Agile Manifesto brought the scientific principles that were used before in other areas to software development. If we analyze the posts on social media and what coaches say at Agile conferences, we can see that the four key values of Agile survived these two decades and maintained their relevance.

Organizations are getting more customer-centric. If 20 years ago, the focus on the client was a brand-new idea, today, it is rather a prerequisite for staying on the market. Customers and the market are changing much faster today, so the Agile attitude to changes has become only more important, though it can be hard to achieve. Sustainable development promoted in the 8th principle is also even more actual today, when the subscription-based software is here and widely used. Companies can polish their software and add new features on the go.

Which Agile Manifesto principles have changed?

The several months’ long timeframe described in the 3rd principle is a rare beast now. In some organizations following continuous delivery, you can easily find terms for software delivery even as frequent as several times a day.

The rise of remote work and online collaboration tools transformed the 6th principle. Though face-to-face communication is crucial, chats and online conferencing tools make it possible to effectively communicate in a team even if members are located in different places.

Overall, the Agile Manifesto is about people helping people and hence it is as relevant today as it used to be when it appeared.

Agile is a mentality

Agile principles existed in people’s minds and in some companies before the Manifesto. Just no one called them Agile. After the Manifesto appearance, a lot has changed in the market, in software development, and even in the way teams are organized. Does that mean that we should also introduce some tweaks to the Manifesto?

The answer is probably “No”. The manifesto is something to start with, the initial point of conversation between companies. Though different teams adjust Agile principles to their processes and needs, they still have one core philosophy and can reach an agreement. All Agile frameworks should be applied at the same time with changing the cultural values. Without cultural changes, the company can face exactly the consequences that it was trying to avoid — micromanagement, burnout-rate pacing, lack of delivery, and adherence to process.