What is Agile? Part One: The Story Behind the Buzzword
This post is one of a series of posts on Agile.
Mar 31, 2021
Agile methodology has been a trending topic for a while now and it typically describes a wide range of approaches to software development, project management, and even raising children. Everyone loves to say they work on an agile team or to describe their company as an agile organization. While it’s true that its widespread use has changed the way people work, the details around agile have started to become diluted to the point where no one really knows what it means anymore. The Agile Alliance, an organization that supports those who use Agile, defines it broadly as “the ability to create and respond to change.” This post is the first in a series aimed at unpacking this buzzword and how the set of ideas it represents can be used effectively in international development contexts.
To better understand how agile became adapted to its current uses, we have to go back a few decades. Traditionally, software development was done using a methodology called “waterfall” where each team would work on something and then pass it along to the next team, and so on. Starting in the 1990s, developers started to push the boundaries of the “waterfall” approach and come up with new ways to tackle software development. These different methods and approaches had been evolving for years before they were more formally understood as “agile methodologies.” A group of these like-minded developers from different innovative approaches got together, drafted the Agile Manifesto in 2001, and thus “agile” was born. The manifesto was a way for software developers who felt that a new approach was needed for software development to come together, find common ground, and help organize the principles behind their thinking.
The manifesto is more about outlining the values behind agile and the mindset of the founders than it is about any specific way to put the methodology to use. This approach to the manifesto is really the core of what agile is all about—it is not meant to be prescriptive, but rather a way to conceptualize how a team thinks about achieving its goals, utilizing common themes. For example, there is a strong emphasis on collaboration and team dynamics in all versions of agile implementation, which you can see are core tenets of the manifesto:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Agile’s 12 Principles
The Agile Manifesto is supported by 12 Principles that serve as the foundation for whatever form agile takes when implemented. These principles are, in my opinion, the most important parts of agile to follow if you plan on trying to utilize it in your work. No matter which form of agile you are working in or how you plan to adapt its tools to meet your needs, following the principles is the key to knowing you are really using agile. The Principles 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 for 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 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 its behavior accordingly.
One of the beauties of agile is that since it was created by a group of developers who all used different frameworks, strategies, and tools, it is more focused on the common values than it is on any one way to do things. This has helpful applications for the international development community as our work is affected by various contexts and operating environments.
Just as when it was founded, there are still several types of agile under the umbrella of the larger methodology, such as Scrum or Kanban. In the next part of this series, I will go over some of the different types of agile frameworks as we dive deeper into how these concepts and ideas are put into practice.