What "Agile" Really Means

Nowadays almost every software development company and team claims to be agile and usually follows some kind of agile methodology. However in the middle of the whole agile movement the real meaning of "agile" is often lost. What does it mean to write code in an agile way? Or to work in an agile team, deliver a product in an agile fashion?

Where has the meaning behind agile disappeared - and what does it really mean at its root?

What does it mean to deliver a product in an agile fashion?

The Birth Of Agile

Let's take a step back to where it all started. In 2001, 17 pretty well-known software craftsmen gathered in Utah to summarize their views on efficient software development in a short document. The outcome of this meeting was the Agile Manifesto which forms the basis of agile software development (and marks the start of the agile movement). The 4 values the agile manifesto states are these:

- 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's pretty much it. So why does "agile" seem to be something much more complex and difficult to grasp these days?

Agile Methodologies and Certifications

14 or so years after the beginnings of agile software development, agile is pretty much a synonym to following some agile methodology, the most popular without doubt being Scrum.

Today, agile is pretty much a synonym to following some agile methodology.

And it's little wonder it's so popular: for starts the methodology is very credible, as it was developed by Ken Schwaber and Jeff Sutherland, two of the members of the Agile Manifesto. Getting started with methodology is pretty easy - there are tons of online resources and more structured Scrum Master courses as well. 

Scrum is also super popular because it's really simple to implement and follow. Implement a couple of lightweight ceremonies on a schedule - standups, backlog groomings, plannings and retrospective, and that's basically it. And results will come fast even if leaving out certain ceremonies. 

It's not just Scrum, but a bunch of other agile methodologies and tools that are gaining traction. Kanban is another popular one, as well as Scrumban (mixing Scrum & Kanban). Extreme Programming is also a tool that although fewer teams use, but those who do absolutely swear by it.

I've used Scrum, Kanban and Scrumban with various teams and projects, sometimes strictly sticking to their processes and other times loosely following recommendations. Still, the more I use these methodologies to build software in an agile way, the more I'm certain that following an agile methodology is not what agile software development is about.

Back to Basics

Building software in an agile fashion will always be speedier, team members will be more motivated and overall outcomes will be better compared to the plan-months-ahead waterfall style development. As the benefits are immediate it's little wonder that a whole consulting and training industry has spurred to help teams and companies transition to agile with the use of agile methodologies and workflows.

The word "agile" has been so overused in the software industry - not the least by consultants making a living off of it - that it has now pretty much lost its original meaning. This is what Dave Thomas, one of the founders of the Agile Manifesto says in a recent post. One of the four values of the Agile Manifesto is individuals and interactions over processes and tools.

So why is it that all agile methodologies introduce more processes and tools in order to achieve agility? Does this not go against the original ideas of agile? Dave - rightfully - says that it's time to ditch the methodologies and get back to the basics of agile.

Individuals and interactions over processes and tools

The Real Meaning of Agile

Doing something in an agile way means making a small change quickly, learning from it, making adjustments to our understanding of the problem and repeating this many times. This is what doing something with agility means:

What to do:

• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned
• Repeat

How to do it:

• When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

These few simple steps are really what agile is all about. Stick with these basics and you can apply them to all parts of software development:

• When writing code, do it in an agile way. Decide what you want to achieve, do a small change, test it, learn from it, adjust and repeat. Try to write code that's easy to change later.
• When building a product, do it in an agile way. Do small changes, get immediate feedback, do small iterations and make decisions that allow future changes as much as possible
• Similarly, when working as a team, solve problems using these basic principles, a small step at a time
• The tools and methodologies you use should help achieve this kind of agility. If they only add more process - ditch them.

The most successful engineers, teams and products all follow these simple steps one way or the other. Agile is not a methodology with rules and processes to follow. At its roots agile is a simple and fast way of learning and improving by taking small steps, one after the other.

Put this principle first and make sure whatever light- or heavyweight process you follow helps achieve this kind of agility.

[This article was originally published on the Pragmatic Engineer blog, where you can read more articles on software engineering, such as The Software Development Dilemma: Move Fast without Breaking Things? and A Comment is an Invitation for Refactoring.]