A funny thing has happened over the last couple of years…. we started calling waterfall software development… er… “waterfall”. By this I mean, we never had a name for the process… waterfall was just called “software development”. There was no distinction or name for what we were doing- there was only one way. This is a draw of agile, it’s something different.. and it’s the only new development methodology to actually get attention in the last 10 years.
So, what’s the deal?
#1) Agile is an umbrella term for several methodologies.
Agile encompasses a lot of different things; it can mean different things to different people. This might be why people have such a hard time understanding it. So comparing “waterfall” to Agile isn’t entirely accurate, or possible, since it’s like comparing one NBA team to all of MLB. Agile encompasses several methodologies (such as XP, Scrum, Kanban), which are all iterative in nature… that brings us to…
#2) Agile is iterative.
Yes, agile is an umbrella term, but all of the methods in agile share common core values: The fundamentals are to incorporate iterative development and to have continuous feedback so that you can always improve. This means you continuously plan, continuously test, and continuously integrate so you can adapt when needed.
#3) Agile is adaptive, not predictive.
Do you remember what “waterfall” was like back in the day? We spent months gathering business requirements, writing specs, and designing, and then spent the next 10 months coding. Since we spent the first few months trying to predict what the next 10 months would entail, we could never accurately estimate how much work a task was supposed to be, and heaven forbid the requirement changed half way through! Agile is an attempt to shorten that cycle so we don’t have to waste 10 months before find out something was wrong.
#4) You can pick and choose what methods you want to implement.
It’s funny. I ask people all the time, “How agile are you?” They typically say “Well, we’re somewhat agile, but not fully agile.” People tend to measure some sort of agile “zen” in their head, and that doesn’t exist! If you’re practicing some agile methodologies, you’ve won half the battle.
You’ve won half the battle if you are practicing:
· Continuous Integration
· Agile Workflows
· Test Driven Development
· Short Iterations
· User Stories
There’s no out of the box way to do this, but if these methods work for you… then you’re there.
#5) The genius Of Agile is in the name.
Since the word “Agile” can’t be traced back to a specific methodology like “waterfall” we probably won’t ever think of it as “development”. In addition since it’s not a prescribed method of doing things (ex: Watefall.. requirements->design->implementation->verification->maintenance) it just can’t fail… whatever methods we use can always be improved and adapted to best suit our needs.
“Agile” is an elitist term and should be banished from the vernacular. It tends to divide people and teams rather than bring them together.
“All of Agile is project management but not all project management is Agile.” — Richard Bucker
You could have called it “mass-production.” The principles and structures are remarkably similar (which is also why many people also like “Lean” Software Development, an optimized version of production)
The reason it wasn’t generally referred to as Waterfall – no one was trying to tell you it was the latest and greatest thing since sliced bread – of course it would have helped if people actually followed a system, but all to often it was a group of disjointed acts and not a process.
I recall from my days at college (early 90s) the term waterfall wrt software development – so went to check one of the books on my bookshelf from those days “Principles Of Software Engineering Management” – sure enough it mentions waterfall, but surprisingly first mention was in chapter titled “An introduction to the ‘Evolutionary delivery’ method.” (mentions frequent iterations) – where have I heard such things before :s
I also recall the lecturer mentioning various failures in processes (but then he introduced us to mythical man month as well) – I suspect I might put them both on the pile to re-read
http://www.amazon.com/Principles-Software-Engineering-Management-Gilb/dp/0201192462/ref=sr_1_3
Not so true… while I was studying Software Engineering we revisited many models, including “waterfall”
It did have a name, it was called “the” Software Development Lifecycle (SDLC) and iterative, incremental processes were positioned in opposition to it as early as 1986.
“Those who do not remember their past are condemned to repeat their mistakes” — Santayana
#4 on measuring “Agility” surprises me. I would’ve said that if all those 5 techniques are being used consistently (and correctly!), that’s much more than “half the battle”. What’s the other half? In my experience, people who are new to Agile often interpret it as just switching to smaller, faster, more numerous iterations. Those people are less than half the battle…
I seem to remember that between “Waterfall” & “Agile” we had the “Spiral” model. My Software Engineering Textbook didn’t mention Agile, but there were at least 3-4 development models in there, including “Waterfall” & “Spiral”, as well as an early version of “Agile” I think they called “Iterative”.