If you’re not familiar with agile, or the Agile Manifesto, or have heard the terms but still don’t fully grasp what they are about, then you’re not alone. Agile and the Agile Manifesto can be difficult to understand for the uninitiated. Understanding both agile and the Agile Manifesto requires an open mind that is receptive to being guided by ideas and concepts, instead of by rigid frameworks and processes. Before understanding the Agile Manifesto it’s important to understand what agile is.
The challenge is that agile means different things to different people. Similarly, there are many ways to interpret and apply the Agile Manifesto. The phrase agile software development was first used in 2001, as a direct consequence of the development of the Agile Manifesto. How this Manifesto was developed is described in the next section about the history of the Agile Manifesto. The ideas behind agile were, in fact, be applied to projects and software development since the mid-1990s. Software developers started to emphasize close collaboration between teams and stakeholders, frequent delivery of business value and self-organizing teams. But until the publication of the Agile Manifesto, these ideas weren’t codified.
Responding to change
According to the agile alliance, the developers of the Agile Manifesto, “Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.” In other words, agile in general and agile as described in the Agile Manifesto are about adaptiveness and responding quickly to changes as they come up, as they will always do. Hence agile and the Agile Manifesto are a way of thinking, not a methodology. This prevents the Agile Manifesto and agile methods becoming rigid and frozen in time. The importance of supporting and embracing change is made very clear in the Agile Manifesto. Hence agile and the Manifesto have become widely adopted within the fast-changing world of software development, which is fraught with uncertainty and risk. Agile and the Agile Manifesto provide a framework of concepts in which to respond and adapt to those changes.
The Role of Cross-Functional Teams
Agile focuses on collaborative teams that are self-organizing and cross-functional. The Agile Manifesto itself has nothing about teams. This is covered by the supporting Twelve Principles of Agile Software that was developed by the same authors as the Agile Manifesto. In agile, self-organizing cross-functional teams come up with solutions to issues themselves, and each team member has multiple skills sets. Agile Manifesto and the supporting Twelve Principles of Agile Software help to set the guidelines for behaviors and priorities when operating in an agile manner.
Agile and the Agile Manifesto
The Agile Manifesto is a published and freely available set of value statements that form the foundation of agile software development. The Agile Manifesto is at the core of the agile movement. Agile as influenced by the Agile Manifesto has an emphasis on efficient production, collaboration, communication, and rapid development of smaller sets of features under the guidance of an overall plan. The key to its success by applying the Agile Manifesto is to remain agile and be willing and able to adapt to change. Embracing the four values in the Agile Manifesto and the supporting Twelve Principles for Agile Software will lead to the delivery of higher-quality software to satisfied customers on a continual basis.
All manifestos, including the Agile Manifesto, are a public declaration of policy and intention. There have been manifestos for art movements, political movements and just about anything you can think of. The Agile Manifesto was the first to address the challenges of software development.
The Agile Manifesto is very short, just 68 words. However, the 68 words in the Agile Manifesto were chosen with great care and skill. In just a few sentences the authors of the Agile Manifesto articulated four fundamental values that will change how you think about software development forever. The Agile Manifesto is supported by the Twelve Principles of Agile Software.
This is what the Agile Manifesto says:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
The publication of just these few words in the Agile Manifesto, online in 2001, revolutionized the thinking for how products should be designed and delivered.
The Agile Manifesto’s full title is ‘Manifesto for Agile Software Development’. That’s because the Agile Manifesto was originally designed to tackle issues in this aspect of IT. However, the values contained in the Agile Manifesto can and have been successfully applied to other areas both within and outside IT. Examples of where the Agile Manifesto has been used include IT service management, project management, and non-IT product development.
Agile can be a controversial topic in IT and IT service management (ITSM). Some call it a methodology, while others refer to it as a framework. Agile isn’t either of these, and neither is the Agile Manifesto. Agile and Agile Manifesto promotes a fast and nimble way to work that focuses on meeting user requirements efficiently and effectively. Agile and the Agile Manifesto initially benefited software development, but are now in use across many sectors and many industries, both within and outside of IT. As an example, agile and the concepts set out in the Agile Manifesto have been adopted within project management, often displacing their traditional project management approaches using Gantt charts and sequential waterfall approaches.
The Agile Manifesto and the Twelve Principles of Agile Software that support the Agile Manifesto were the consequences of industry frustration with software development in the 1990s. There was a long-time lag between capturing business requirements and delivering the solution to meet them. Without the values contained in the Agile Manifesto, the final product often did not meet the user's needs. The software development models of the day, such as the waterfall model, were not agile and did not meet the demand for speed. Thought leaders in software development realized that something like the Agile Manifesto was required to address these issues.
The creation of the Agile Manifesto started in the spring of the year 2000 when some proponents of Extreme Programming proponents and others met in Oregon, USA. At this meeting attendees, many of whom were later signatories to the Agile Manifesto, voiced support for a variety of "Light" software development methodologies. However, at this stage, the term ‘Agile Manifesto’ wasn’t mentioned and nothing formal was created.
During 2000 a number of articles were written that referenced the category of "Light" or "Lightweight" processes, but still no mention of agile or Manifesto. In conversations, no one really liked the moniker "Light", but it seemed to stick for the time being.
In September 2000, Bob Martin from Object Mentor in Chicago, and a signatory to the Agile Manifesto started the next meeting ball rolling with an email; "I'd like to convene a small (two day) conference in the January to February 2001 timeframe here in Chicago. The purpose of this conference is to get all the lightweight method leaders in one room.” Bob set up a Wiki site and the discussions started, but still, there was no mention of an Agile Manifesto.
Early on in the development of the ideas that emerged in the Agile Manifesto, concerns were raised about using the word ‘Light.’ During the development of the Manifesto, the word agile was used instead of light, as it better conveyed the purpose.
In February 2001 a group of seventeen people met In Utah to develop what became the Agile Manifesto. The participants wanted to create an Agile Manifesto to provide an alternative to the documentation driven, heavyweight software development processes that existed at the time. This group developed the Agile Manifesto in just two days.
The participants who developed and agreed the Agile Manifesto all worked in software development. They wanted to create a Manifesto that could guide agile development and be applied to all methodologies. This Agile Manifesto had to be easy to understand and freely available to all. To ensure adoption by all those involved in developing software in an agile way, the participants in the development of the Agile Manifesto represented the wide range of different methodologies that are used to develop software.
Before the Agile Manifesto was created, these methodologies focused on processes and documentation. The Agile Manifesto supplemented these by a set of shared values, focusing on the customer.
This group of people who created this Agile Manifesto named themselves ‘The Agile Alliance’. This collection of independent thinkers about software development, and sometimes competitors to each other, agreed on the title, ‘Manifesto for Agile Software Development’, which soon became known as the Agile Manifesto.
Whilst the Agile Manifesto set out some specific ideas; there was a deeper theme that drove many of the Agile Alliance. The people who created the Agile Manifesto held a set of compatible values, a set of values based on trust and respect for each other, promoting organizational models based on people, collaboration, and building the types of organizational communities in which they and we would want to work.
The concepts in the Agile Manifesto were soon taken up by many across the spectrum of software development. These ‘Agile Methodologists’ saw the value of delivering good products to customers by operating in an environment that does more than talking about "people as our most important asset" but actually "acts" as if people were the most important thing. Resonance with these values drove a very rapid rise in interest, adoption, and criticism of the Agile Manifesto.
The core values from the Agile Manifesto all derive from the words in the Manifesto itself. These words were carefully crafted by the members of the Agile Alliance, the people who developed the Agile Manifesto. The few rods in the Manifesto cleverly set out the core values at a high yet understandable level. Anyone reading the Agile Manifesto should be able to relate these to their own circumstances and be able to recognize issues in their own organization and processes which are contrary to these Agile Manifesto values.
Here is a reminder of what the Agile Manifesto says:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
The first part of the Agile Manifesto
The first paragraph in the Agile Manifesto neatly gets across several things:
New ways of developing software have been discovered, and are continuing to be discovered. The use of the word ‘uncovering’ in the Agile Manifesto makes it clear that the work hasn’t ended, there is more to do.
The better ways of developing software aren’t just theory. Using the phrase ‘by doing it’ I the Agile Manifesto gets across that the authors of the Manifesto have hands-on experience of developing software in an agile way.
The authors of the Agile Manifesto have helped others to develop new ways of working. This is an important concept in the Agile Manifesto and its application. The Agile Manifesto makes it clear that developing new ways of working should be a collaboration, helping others on the journey.
The first sentence in this paragraph makes it clear that these new ways to develop software are an improvement on previous approaches. This sentence in the Agile Manifesto doesn’t say who benefits from these better ways of working. To understand that you need to consider the four values in the next paragraph.
The last sentence in the first paragraph of the Agile Manifesto gets across that the work has led the authors of the Manifesto to understand the values that should be applied to developing software in an agile way.
The Values of the Agile Manifesto
For some organizations, applying the values set out in the Agile Manifesto may be straightforward. For others, it may be more challenging, particularly as the changes driven by the Agile Manifesto tend to require changes to attitude, behaviors, and culture. This can’t be bought in an ‘Agile Manifesto kit’.
Before we take a more detailed look at each of the value statements in the Agile Manifesto, it is important to understand that you need to take more than just a cursory glance at these values. To fully understand the messages that the Agile Manifesto contains, and the changes in behaviors and actions that the Agile Manifesto is trying to drive, the reader needs to read and get under the meaning of each word and phrase in the Agile Manifesto. Then, with an open mind, they need to consider what they have understood from the Agile Manifesto against the current situation in their own organization. Only then can they start to develop actions for applying the Agile Manifesto in their own organization.
1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Valuing people more highly than processes or tools is contrary to how some organizations seem to behave. The Agile Manifesto has this as its first value because people are the most important asset in any organization. It is people who respond to business needs and who drive the development process, whether this is agile as set out in the Manifesto, or not. Valuing people and how they work together are arguably the most important values in the Agile Manifesto. The meaning of the word ‘interactions’ in the Agile Manifesto is concerned with how individuals work together, as a team.
Applying just this single value from the Agile Manifesto can deliver great results. If more value is given to the items to the right of this line in the Agile Manifesto, then processes or tools can drive software development. Ignoring this part of the Agile Manifesto can mean that teams are less responsive to change, less supportive of changes to ways of working, and hence less likely to meet customer needs. Analyzing just this single statement in the Agile Manifesto can give surprising results. For example, if an organization wants to value individuals and interactions more, then it has to look at changing attitudes, behaviors, and cultures. Hence successfully applying the values from the Agile Manifesto usually requires the skills of organizational change management.
2. Working Software Over Comprehensive Documentation
Historically, and before the Agile Manifesto, considerable effort was spent on documenting the product for development and ultimate delivery. This included technical specifications, technical requirements, technical designs, interface design documents, test plans, test results, acceptance criteria, and documentation plans, with reviews and approvals required for each. Either organization didn’t do any of this with subsequent risks to live service and support, or they tried to do everything that led to long delays in development. Before the Agile Manifesto, it was not uncommon for software to be perfectly documented, but not actually deliver what the user wanted. Or the software would go live and be full of errors.
This line in the Agile Manifesto was aimed at making a massive change in attitude. Working software is very important. Agile does not eliminate documentation, but this value from the Agile Manifesto challenges documentation, so only what is essential is produced. One example of how the Agile Manifesto is applied is the concept of ‘user stories.’ These are a short statement of what the user wants to do, freeing up the developers to deliver what is required without the need for detailed specifications and designs. This value from the Agile Manifesto also allows developers to make changes as they learn more, which is a good illustration of the Agile Manifesto valuing individuals more than processes.
3. Customer Collaboration Over Contract Negotiation
Contract negotiations are still important when an organization contracts delivery to an external organization. The meaning of negotiation in the Agile Manifesto can be taken in two ways.
Negotiation can be the activities undertaken between the customer and the supplier to agree who will do what, and the products that are to be delivered, before the contract is signed and delivery commence.
Negotiation, as implied by the Agile Manifesto, can also refer to events after delivery has started, when disputes arise over delivery.
This line in the Agile Manifesto is trying to move away from the pre-signing situation where the customer tries to think of everything that might happen and tries to put clauses into the contract to force the supplier to act in particular ways. Before the Agile Manifesto, some contracts even specified the software development approach that the supplier must use. Applying this value from the Agile Manifesto should mean that contractual requirements are kept to a minimum and that a culture is created where the customer and supplier will collaborate as new situations arise, and not just fall back onto the contract.
The interpretation of this line in the Agile Manifesto for post-delivery is about adverse behaviors if something goes wrong. Instead of leaning heavily on the contract trying to blame the supplier, the Agile Manifesto tries to encourage the customer and supplier to collaborate to find a solution. This puts the focus back onto getting the service working again, avoiding delays in resolution whilst the lawyers review the contract. If correctly applied, the Agile Manifesto can change the customer to be one that engages and collaborates with suppliers throughout the development process, effectively working as a single team. This makes it far easier for developers to meet the needs of the customer, especially if they change.
4. Responding to Change Over Following a Plan
Before the Agile Manifesto, traditional software development approaches had long lead times between capturing requirements and delivering the software. This led to a reluctance to making any changes once the requirements had been signed off. The waterfall methods that were prevalent before the Agile Manifesto typically included the development and management of detailed plans, with long lead times between each development stage, and delivery against plan taking priority over everything else.
This line in the Agile Manifesto started a fundamental move away from that approach. Instead of long and heavily prescribed development cycles, the Agile Manifesto resulted in developments being done in short, agile, iterative cycles. Each iteration delivers a small incremental change. This fundamental concept from the Agile Manifesto revolutionized the way that software is developed, driving a change across the whole software industry. The short iterations sparked by the Agile Manifesto mean that priorities can be shifted from iteration to iteration, and new features can be added into the next iteration, as user requirements change. The Agile Manifesto sees all changes as providing value, not something to be avoided.
Changes in this context from the Agile Manifesto also include changes to ways of working. One example of applying this concept from the Agile Manifesto is Method Tailoring. This can be defined as ‘A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.’ Hence the application of this value from the Agile Manifesto can allow teams to modify their own processes and working practices, tailoring them to how they want to work instead of having to ask for higher authority before making the change.
The Agile Manifesto is comprised of four foundational values and twelve supporting principles which give a framework of values to guide developing software in an agile way. Each organization and agile development methodology can apply the four values set out in the Agile Manifesto in different ways. But if the Agile Manifesto is understood and followed, then the Manifesto will enable all of these different methodologies to efficiently and effectively deliver high-quality, working software to the users and customers.
The way that the Agile Manifesto was set out by its authors is deliberate. The individual values that are written out in bold are all listed to the left of the Agile Manifesto page. That is explained by the last paragraph in the Agile Manifesto – those in bold are to be valued more by the organization that is applying the Agile Manifesto.
The way that each line is indented in the Agile Manifesto is also deliberate. This formatting of the contents of the Agile Manifesto assist readability and invite the reader to read and consider each separate point. If these values had been laid out in the Agile Manifesto in a long list, or a table, it is probable that the Agile Manifesto would not have made such a significant impact to agile in general, agile software development, and uses of the Manifesto outside agile software development.
The Agile Manifesto does not say that the values set out on the right-hand side are bad. The Agile Manifesto also does not say that the activities related to the value on the right-hand side should not be done. The Manifesto says that those to the left are valued more than those to the right. The authors of the Agile Manifesto carefully chose this way to get across their message. IT has too often had new initiatives that set themselves out to be the only way to do things. The Agile Manifesto doesn’t do this, it provides a new way of thinking about software development. Instead of focusing on technologies and processes, the Agile Manifesto gets across the idea that softer aspects are more important to success.
If you look at the items on the right-hand side of the values in the Agile Manifesto, you might recognize that these are what IT and software development historically focused on. For example, frameworks such as ITIL that were around when the Agile Manifesto was developed placed most of the emphasis on processes. New tools for software development and new programming languages, were regularly launched. Before the Agile Manifesto, there was a naive belief that new tools, processes, and technologies would make everything better. At the time before the Agile Manifesto changed thinking, there was a heavy focus on the need for everything to be documented and planned. Both are important, particularly where neither of them exists, but the Agile Manifesto tries to get across the concept that these aren’t the end game.
To help with understanding the Agile Manifesto, the authors also developed twelve principles of agile software. Just like the Agile Manifesto, these principles can be readily applied to many other disciplines and industries. The Twelve Principles underpin the Agile Manifesto. In conjunction, the Agile Manifesto and these principles provide the guide for all of the individual methodologies that are included under the title of ‘The Agile Movement.’ Together they describe a culture in which change is welcome, and the customer is the focus of the work. The principles and the Agile Manifesto demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs.
The Twelve Principles of Agile Software are:
Our 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 to the shorter timescale.
Business people 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 a 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 it's behavior accordingly.
These principles bring the agile manifest to life, and can drive the following behaviors:
The Agile Manifesto has driven an enormous change in how work is done. Instead of work happening in a rigorous way based on set plans and rigid, formal approaches, organizations that have embraced the concepts in the Agile Manifesto now work in a way that is based on collaboration, communication, and trust. This change has gone way beyond what the original signatories to the Agile Manifesto could have envisaged.
The original intention of the Agile Manifesto was to change how software was developed. The Agile Manifesto has been incredibly successful in this IT discipline. Agile, as described in the Manifesto, soon helped the software development community to get away from the straightjacket of up-front planning, analysis paralysis, and its siloed waterfall approaches to engagement with users. Today, the software is developed in short bursts, with new functionality being incrementally delivered in small amounts. Largely thanks to the Agile Manifesto, there has been an explosion of new applications, which themselves have fundamentally changed how we all work. Just think of how you personally used IT products in the days prior to the Agile Manifesto, when there were no smartphones with apps that you can download with a click and no useful apps that you can immediately access in the cloud.
But the Agile Manifesto didn’t just influence software development. Today, agile and the concepts in the Manifesto are cherished as a culture and value system across many parts of an organization, and in just about all sectors. That includes how the world of business operates. Today’s fast-moving world demands the rapid delivery of new products, services, and changes to those products. That’s any type of product, not just software applications. Using the concepts described in the Agile Manifesto make this happen. As an example, the manufacturing industry has embraced the Agile Manifesto. Lead times between the initial concept and the delivery of a new product have been dramatically reduced using agile methods inspired by the Manifesto. Design is done in short iterations, with each delivering a new feature of the product. The Agile Manifesto has changed how an organization structures itself for design and development. Most organizations now have self-determining multi-skilled teams, as set out in the Agile Manifesto and the supporting twelve agile principles.
Many organizations who do IT service management (ITSM) have used the Agile Manifesto to transform how they work, particularly in the discipline of release management. The influence of the Agile Manifesto on ITSM ways of working only really started in the last few years. This was driven particularly by the uptake of the Agile Manifesto by software development, which soon caused issues with the waterfall approach for release management that was described in ITIL. Some ITSM functions still resist the concepts of the Agile Manifesto, preferring to keep long release cycles that deliver a lot of functionality in one go. This is contrary to the Agile Manifesto and is definitely not agile. Agile release management embraces the Agile Manifesto, bringing together ITSM and software development so that they act as a single multi-disciplinary team. Work is done in short iterations, in an agile way as described in the Manifesto, regularly delivering working software to the customers. ITSM overall is undergoing a transformation in the way that it works, with increasing adoption of the Agile Manifesto across all ITSM practices. Organizational structures with ITSM staff siloed by practices, such as release management, change management, and problem management, and project management are being replaced by ones that align with the values in the Agile Manifesto. Instead, small multi-skilled ITSM teams are aligned to the product delivery teams from software development, as these software teams re-aligned themselves in this way in order to maximize the benefits from adopting the Agile Manifesto.
The Agile Manifesto will continue to transform the way that we work and think. Agile and the Manifesto have created a cultural and behavioral shift in how work is organized and done. Working in an agile way as promoted by the Manifesto encourages the development of individuals and team working, whilst at all times thinking about what the customer wants. Agile as set out in the Manifesto isn’t a theory that is waiting to be proved, agile is an accepted way of working for now and for the future.
Sorry, our deep-dive didn’t help. Please try a different search term.