What is Agile?
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 more than frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).
Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints.
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 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 helps 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
Many 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 before 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 might 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 Programming, 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 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.
They didn’t agree upon a lot of things, 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 to 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 Agile Manifesto’s values and principles. 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.
Keep the values and principles in mind when you do this. Let your context guide which frameworks, practices, and techniques you use to collaborate with your team and deliver value to your customers.
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 will 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 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 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 how 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 is 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.
Key Agile Concepts
Below are a few key Agile concepts. You can see more in our glossary section.
User Stories: In consultation with the customer or product owner, the team divides up the work to be done into functional increments called “user stories.” Each user story is expected to yield a contribution to the value of the overall product. (see more)
Daily Meeting: Each day at the same time, the team meets so as to bring everyone up to date on the information that is vital for coordination: each team members briefly describes any “completed” contributions and any obstacles that stand in their way. (see more)
Personas: When the project calls for it – for instance when user experience is a major factor in project outcomes – the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called “personas.” (see more)
Team: A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis. A small minority of team members may be part-time contributors, or may have competing responsibilities. (see more)
Incremental Development: Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality. (see more)
Iterative Development: Agile projects are iterative insofar as they intentionally allow for “repeating” software development activities, and for potentially “revisiting” the same work products. (see more)
Milestone Retrospective: Once a project has been underway for some time, or at the end of the project, all of the team’s permanent members (not just the developers) invests from one to three days in a detailed analysis of the project’s significant events. (see more)
Join us today!
Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now for just $49 per year.