What is agile?

Forget everything you've ever learned about agile development.
373 readers like this.
a big flag flying in a sea of other flags, teamwork


I know you are thinking, "Not another Agile 101 article!" We were, too. There are many resources that describe what agile is, talk about the history of the concept, and go into depth about why it is important. This article is not any of those things—rather, we would like you to forget everything you've been told; everything you've learned, read, or otherwise acquired via misuse of the term or misdeed in implementing it.

Before we unpack the word agile, we want to set some context. In February 2001, the Agile Manifesto was written by 17 people who represented a variety of different software development methods. While they all represented different areas, they had one thing in common—they felt a need to find an alternative to the heavyweight software development process that was most common at the time. It was this meeting, as well as the follow-up rallying cry by the industry, that brought agile into the forefront today.

However, because of the proliferation of information around "agile" on the internet and the tendency for companies to move towards certain methodologies over others, there is often a default thought that agile must equate with the methodology of Scrum. At Red Hat, we view this a lot simpler than that. Instead of immediately diving into methodologies and how to do things, we ask our associates to focus on the first sentence of the manifesto...

"We are uncovering better ways of developing software by doing it and helping others do it."

...and stop there—everything that comes after is subject to your own experiences and is generally based on your personal circumstances.

Here's what those words mean.

Uncovering better ways

This casually refers to the ideal that continuously improving is paramount above all other processes. Yes, this means having a perspective on what is going well or not going well. But, it is far simpler than that. It refers to the simple act of getting better at what you do as time goes on, and that includes your people, technical tooling, and workflow processes.

Developing software by doing it

There isn't much hidden behind these words, although we often associate this with the concept of teams who are able to digest requirements, make decisions on the fly, and work self-directedly to achieve an outcome for their customers. The key point here is that it isn't conceptual—you are spending your time experimenting with what works for your customers vs. having a conversation ad nauseam about what is possible before beginning work.

Helping others do it

Finally, this brings in the human element of agile—the part where teams are encouraged to talk, share, teach each other, fail safely together, and be kind to everyone while they are working in what amounts to be a stressful industry with many deadlines—hopefully encouraging folks to love their jobs.

While it may be hard to ignore the juxtaposition between the original intent of the manifesto vs. what agile looks like today, there is a strong growing sense of bringing it back to the basics. The best way to do so is to not get bogged down by the multitude of ways to get work done, but rather focus on the spirit and intent of the original words written in 2001.

What to read next
User profile image.
Jen Krieger is Chief Agile Architect at Red Hat. Most of her 20+ year career has been in software development representing many roles throughout the waterfall and agile lifecycles. At Red Hat, she led a department-wide DevOps movement focusing on CI/CD best practices. Most recently, she worked with with the Project Atomic & OpenShift teams.
Technical Marketing, Developer Advocate, CNCF Ambassador, Public Speaker, Published Author, Quarkus, Red Hat Runtimes
Barcelona atop the fort overlooking the city
Matt is passionate about adapting working environments to innovate, while ensuring individuals and interactions are never sacrificed. As a part of the Red Hat Open Innovation Labs team, he supports delivery using Labs culture and open principles to cultivate a better way of working.


It's a silver bullet. If it doesn't work for you, that's because you are doing it wrong. Or might it be the case that it just another fad to the long list of fads in the industry?

Interesting notion to call it a silver bullet. Is there a particular piece of the the values found in the Agile Manifesto that you disagree with, or feel will not be helpful to improve a team's ability to deliver business value? Keep in mind, This is not a methodology to where you get steps on how to work, but a set of behaviors and principles to keep in mind as you determine how you wish to implement how you work.

It would be interesting to see if these kinds of values were ever well popularized or consolidated prior to the Snowbird meeting in 2001.

In reply to by Jay Sanders (not verified)

There is one book named: "Agile. The Good, the Hype and the Ugly" by Bertrand Meyer.

The best quote from this book is:
"Your new is not good and your good is not new"

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.

Download the Open Organization Guide to IT Culture Change

Open principles and practices for delivering unparalleled business value.