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.
The authors of the Agile Manifesto chose “Agile” as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach.
It’s really about thinking through how you can understand what’s going on in the environment that you’re in today, identify what uncertainty you’re facing, and figure out how you can adapt to that as you go along.
What is Agile Software Development?
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.
One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.
There’s a big focus in the Agile software development community on collaboration and the self-organizing team.
That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.
It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.
There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.
When most teams and organizations start doing Agile software development, they focus on the practices that help with collaboration and organizing the work, which is great. However, another key set of practices that are not as frequently followed but should be are specific technical practices that directly deal with developing software in a way that help your team deal with uncertainty. Those technical practices are essential and something you shouldn’t overlook.
A Short History of Agile
Here is a look at how Agile emerged, how it acquired the label Agile, and where it went from there. It’s important to take a look at where Agile software development came from to get an understanding of where things are at today.
Pre 2001 – Practices and Methods Develop Independently through Experience
A lot of people peg the start of Agile software development, and to some extent Agile in general, to a meeting that occurred in 2001 when the term Agile software development was coined.
However, people started working in an Agile fashion prior to that 2001 meeting. Starting in the mid-nineties, there were various practitioners, either people working inside organizations developing software products or consultants helping organizations build software who thought, “You know what? The way we’ve been building software just isn’t working for us. We’ve got to come up with something different.”
These software developers started mixing old and new ideas, and when they found a combination that worked, they created a methodology for their team to help them remember the combination of ideas that worked in a given situation.
These methodologies emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, tight, self-organizing teams; and smart ways to craft, confirm, and deliver code.
The people who created those methodologies figured that others may be interested in getting some of the same benefits they were experiencing, so they created frameworks to spread the ideas to other teams in other organizations and contexts. This is where frameworks such as Scrum, Extreme Programing, Feature-Driven Development (FDD), and Dynamic Systems Development Method (DSDM), among others, started to appear.
The spread of the ideas at this time was very organic, and all of those different approaches started to grow in a very grassroots manner. People borrowed the original frameworks and tweaked them with different practices in order to make them appropriate for their own contexts.
2001 – Agile Manifesto Authored
There wasn’t a consistent way of describing these different ways to develop software until a group of 17 people thought, “We’re all doing these different approaches to developing software. We ought to get together and see where there are commonalities in what we’re thinking about.” The result was a meeting at a ski resort in Snowbird, Utah in 2001.
When they got together, they did some skiing and also discussed where their approaches to software development had commonalities and differences.
There were a lot of things that they didn’t agree upon, but there were a few things that they were able to agree upon, and that ended up becoming the Manifesto for Agile Software Development. The two main things the Agile Manifesto did was to provide a set of value statements that form the foundation for Agile software development and to coin the term Agile software development itself.
In the months afterward, the authors expanded on the ideas of the Agile Manifesto with the 12 Principles Behind the Agile Manifesto.
Some of the authors, including Martin Fowler, Dave Thomas, Jim Highsmith, and Bob Martin, wrote up their recollections of writing the Agile Manifesto. 16 of the 17 authors met at Agile2011 and shared their recollections of the event and their views on the state of Agile up to that point.
Post 2001 – Adoption Started Grassroots, Became Mainstream
After the authors got back from Snowbird, Ward Cunningham posted the Agile Manifesto, and later the 12 Principles online at AgileManifesto.org. People could go online and sign it to show their support.
Agile Alliance was officially formed in late 2001 as a place for people who are developing software and helping others develop software explore and share ideas and experiences.
Teams and organizations started to adopt Agile, led primarily by people doing the development work in the teams. Gradually, managers of those teams also started introducing Agile approaches in their organizations.
As Agile became more widely known, an ecosystem formed that included the people who were doing Agile software development and the people and organizations who helped them through consulting, training, frameworks, and tools.
As the ecosystem began to grow and Agile ideas began to spread, some adopters lost sight of the values and principles espoused in the manifesto and corresponding principles. Instead of following an “agile” mindset, they instead began insisting that certain practices be done exactly in a certain way.
Organizations that focus solely on the practices and the rituals experience difficulties working in an Agile fashion. Organizations that are serious about living up to the Agile values and principles tend to realize the benefits they sought and find that working in an Agile fashion is no longer something that’s new and different. Instead, it simply becomes the way they approach work.
Agile Alliance continues to curate resources to help you adopt Agile practices and improve your ability to develop software with agility. The Agile Alliance website provides access to those resources including videos and presentations from our conferences, experience reports, an Agile Glossary, a directory of local community groups and several other resources.
Agile is a Mindset
Ultimately, Agile is a mindset informed by the values contained in the Agile Manifesto and the 12 Principles behind the Agile Manifesto. Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty.
You could say that the first sentence of the Agile Manifesto encapsulates the whole idea: “We are uncovering better ways of developing software by doing it and helping others do it.”
When you face uncertainty, try something you think might work, get feedback, and adjust accordingly.
What are Agile Methodologies?
If Agile is a mindset, then what does that say about the idea of Agile methodologies? To answer this question, you may find it helpful to have a clear definition of methodology.
Alistair Cockburn suggested that a methodology is the set of conventions that a team agrees to follow. That means that each team is going to have its own methodology. which will be different in either small or large ways from every other team’s methodology.
So Agile methodologies are the conventions that a team chooses to follow in a way that follows Agile values and principles.
“Wait,” you’re probably saying, “I thought Scrum and XP were Agile methodologies.” Alistair applied the term framework to those concepts. They certainly were born from a single team’s methodology, but they became frameworks when they were generalized to be used by other teams. Those frameworks help to inform where a team starts with their methodology, but they shouldn’t be the team’s methodology. The team will always need to adapt its use of a framework to fit properly in its context.
What about Agile Project Management or Agile Business Analysis?
As Agile Software Development became more popular, people that were involved with software development activities but who didn’t personally develop software looked for some way to figure out how these Agile ideas applied in their line of work.
The Agile Manifesto and the 12 Principles were written by a group of software developers (and a tester) to address issues that software developers faced. When you think of Agile as a mindset, that mindset can be applied to other activities.
When you do that, Agile becomes an adjective. It describes the way in which you perform some activity. It does not create a new methodology for the reasons explained above.
When you want to understand Agile project management, ask “How might we perform project management in a way that allows us to create and respond to change and deal with uncertainty?” Agile Alliance and Project Management Institute (PMI) explored this question through a joint effort to create the Agile Practice Guide (Available to Agile Alliance Members).
When you want to understand Agile business analysis, ask “How might we perform business analysis in a way that allows us to create and respond to change and deal with uncertainty?” Agile Alliance and International Institute of Business Analysis (IIBA) explored this question through a joint effort to create the Agile Extension to the Business Analysis Body of Knowledge (Available to Agile Alliance Members).
What about Business Agility?
The two concepts noted above are examples of an attempt to move Agile “outside of software.” Those efforts have resulted recently in the Business Agility movement.
If you extend the idea of Agile as a mindset, then people seeking Business Agility ask themselves, “How might we structure and operate our organization in a way that allows us to create and respond to change and deal with uncertainty?”
You might say that business agility is a recognition that in order for people in an organization to operate with an Agile mindset, the entire organization needs to support that mindset. Agile software development was never truly Agile until the organization changed its structure and operations to work in an uncertain environment.