What is Agile? A History Lesson

To onboard new team members in Blossom we decided to make an agile primer – we don’t expect everyone to be an ‘agile expert’ off the bat.

And now we’re sharing it. Enjoy!

Old School Thought – “Waterfall”

First, some history.

Most software projects used to be run as a series of sequential phases or steps. Something along the lines of:

“Waterfall model” by Peter Kemp / Paul Smith. Licensed under CC BY 3.0 via Wikimedia Commons

It’s what you learn at high school, and it’s what most large organizations still practice.

The (not-so) hidden downside is that it’s sequential. If a requirement is no longer valid during the testing phase or the market has changed, it’s too late. It’s being tested now. Development and requirements are done.

In our hyper-evolving world, this doesn’t quite work in practice anymore. Well, for building great products at least.

They call this approach “waterfall”. Once you go past a phase, you can’t climb back up. It’s a waterfall after all.

As luck would have it, it’s not all bad news.

The waterfall approach suits projects that have requirements which are set in stone. If the requirements don’t change and the rest of the phases are completed at a high quality, you can pack your bags and go home. The project was successful.

But…

In reality, the majority of projects and products are not like this. The market you compete in can change daily and customer feedback can mean your initial idea needs to pivot half way through implementation. At the end of the day, you’re building something for someone. Consequently, their opinions are pretty important.

New School Thinking – ‘Agile’

So a bunch of people got together in 2001 and decided to create a medicine to remedy the immobility present in the software development practices at the time. They called it The Agile Manifesto.

The manifesto consists of a number of values and principles. In a nutshell, it’s based on quickly and iteratively developing software, with a focus on customer feedback and effective communication between the people that build the software product.

Out of this manifesto spun the concept of Agile Software Development, which is a number of methods that can be used to develop software based off the values and principles in The Agile Manifesto.

Alone, Agile Software Development doesn’t do much for teams. It’s the agile software methods that provide teams structure on how to manage and build products. What these methods have in common is that they help teams to build and release software in small, frequent iterations, as opposed to taking the ‘big bang’ waterfall approach of releasing software after everything else has been completed.

Adapted from Ifran Ebrahim

Some of these methods include:

It’s important to note that the word ‘agile’ means nothing on its own. Oxford defines it as:

“Able to move quickly and easily.”

See. Nothing to do with software development.

Agile is a mindset

In the software world (and most other industries), being ‘agile’ is a mindset. Practicing some of the above agile methods doesn’t exactly mean that a team is adopting an ‘agile’ mindset. They provide structure to help you be ‘agile’, but the operative word here really is ‘help’.

What is an ‘agile’ mindset, you might ask? Essentially, it’s mostly what’s in The Agile Manifesto. Practically speaking, it’s about hypothesizing ideas, quickly building them, testing them against real customers and then iterating upon them.

Being ‘agile’ is not something that’s exclusive to the software industry, but it has definitely been popularized by it. Recently, there has been quite a buzz around Agile Marketing. And some agile methods themselves are inspired by other industries (the best example being lean manufacturing and the Toyota Production System).

The Evolution of ‘Agile’

Now the funny thing is that out of Agile Software Development and its methods spun another industry:

Agile consultancy.

And it’s mainly for the Scrum framework. This has (ironically) split the co-founders of Scrum into two separate organizations which provide separate Scrum certifications (Scrum.org and the Scrum Alliance).

Because of Scrum’s widespread popularity, many people have begun to confuse Scrum with agile (and ‘agile’ with agile software development, just to add to the confusion). As you can tell, it all gets a bit messy from there.

It’s All About Context

To boot, some of The Agile Manifesto values have been taken out of context. For example, the following value has been taken by countless teams to mean that near-to-no documentation is part of being ‘agile’:

“Working software over comprehensive documentation”

The reality is far from this…

All in all, agile software development has enabled the software development industry to progress. It helps teams build higher quality products in shorter time, which means less waste. Innovation is faster and humanity benefits.

There are many more intricacies that have lead to the rise of Agile Software Development. They are mostly technical, but at core, are industry-wide mindset changes. We’ll describe these in Part 2 of Agile 101.

Until then, keep iterating!

Read on for part 2 and part 3 of the What is Agile? series.