What is Agile?

A History
Lesson
Written by Gerry Claps, VP of Customer Success at Blossom
in Open

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:

 Scrum
 Kanban
 Lean software development
 Extreme Programming (XP)
 Lean Startup (kind of)
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!