What Is Agile History
What Is Agile History
What Is Agile History
A History
Lesson
Written by Gerry Claps, VP of Customer Success at Blossom
in Open
“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.
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.
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
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:
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’:
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!