
What Killed Waterfall Could Kill Agile - fogus
http://cleancoder.posterous.com/what-killed-waterfall-could-kill-agile
======
frossie
Okay, interesting post that left me with a "Well, yes and no" response.

The accusation is, that the "scrum master/coach" role in agile has gone from
being an in-team activity to being a project management activity. I do think
that is true. I also agree that Agile has become a buzzword that companies are
adopting without truly understanding it (in the vein of
<http://www.halfarsedagilemanifesto.org/> )

But the reason Agile won't be killed is the same reason Waterfall hasn't been
killed: it's the optimal choice in some scenarios.

(And before you sneer at Waterfall, go build me a nuclear power station with
Agile).

~~~
gcheong
"(And before you sneer at Waterfall, go build me a nuclear power station with
Agile)"

Or a sudoku solver.

~~~
newt
Meh? I build a suduko solver one night on my own in 2-3 hours. I've seen agile
do much more than that. What are you trying to say?

~~~
mifrai
I think it's referring to the sudoku TDD blog series that happened a few years
back. Essentially, someone tried to implement a sudoku solver using TDD - and
after several posts, never managed to finish. Peter Norvig then came along and
wrote a short elegant implementation.

Some use this to say TDD - which has ties to agile - doesn't work. But most
people conclude that TDD isn't a silver bullet and you have to know about your
problem domain before diving in.

Here's someone elses' blog post which includes links to both sets of posts:
[http://ravimohan.blogspot.com/2007/04/learning-from-
sudoku-s...](http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-
solvers.html)

~~~
newt
Ok, that at least makes sense. But ... sudoku is a _puzzle_ \- you don't (or
at least I didn't) get there by iteration and testing, you get there by a
flash of insight - "if I try searching like this, I might be able to end up
with a solution to any sudoku board" and few hours later I knew I was right.
In that way, it is unlike almost all large-scale software development.

Agile can't generate insight from nothing, it's not a silver bullet. But at
least if you have some unit tests around your cool new code, you know that you
won't accidentally break it later.

------
joshwa
WHY is this posted as an embedded scribd doc?

\--

EDIT: full text posted here: <https://gist.github.com/710960>

~~~
MikeTaylor
Why is anything, ever?

~~~
RodgerTheGreat
A friend of mine who briefly worked for Scribd once tried to convince me that
Scribd enhances the experience of working with PDFs online because it offers
better navigation features than PDF viewer plugins. I'm not convinced, but
perhaps it makes it easier to understand the Scribd users?

------
hartror
Waterfall is dead? I missed that memo!

~~~
jemfinch
Waterfall was DOA. People have just been trying to bring it to life for forty
years.

~~~
kenjackson
Except for the fact that almost everything we use was built with waterfall.
From the CPU/GPU to the OS to my browser and most of my apps... almost all
were likely built with waterfall.

Outside of a few websites, I don't think the full on TDD/Agile blitz has built
much.

~~~
jemfinch
> almost all were likely built with waterfall.

Stop using weasel words. Find real, confirmed examples or keep mum. "Likely"
isn't worth a rebuttal.

~~~
kenjackson
How about the worlds most populat OSes, Windows, Linux, BSD.

Mozilla, Chrome browsers.

Android, iOS, and WinCE.

Word, Excel, Quicken, TurboTax, Photoshop, iLife.

~~~
newt
In what way is chrome's development waterfall?
[http://adtmag.com/articles/2010/07/30/is-google-going-
agile....](http://adtmag.com/articles/2010/07/30/is-google-going-agile.aspx)
And firefox? [http://www.developer.com/open/article.php/3860226/Mozilla-
Fi...](http://www.developer.com/open/article.php/3860226/Mozilla-Firefox-Gets-
More-Agile-with-Lorentz.htm)

Those were the first 2 that I googled. I'm sure that some of them are not
agile, most likely by default - e.g. the older Microsoft ones, before MS or
anyone else discovered agile. But honestly, all you are doing is throwing out
names of popular programs without any idea if they are agile or not, and then
claiming success on the ones that no-body refutes.

After that behaviour, the burden of proof is on you - back each one up with
references or go away.

It would be interesting if you found major projects that evaluated both agile
and waterfall _and still chose waterfall_ or deliberately changed to a less
agile process, instead of the other way. Rather than just software written
before the people involved knew what agile was.

~~~
kenjackson
Both projects you site have assets that are indicative of waterfall. Specs,
designs, and dot releases.

The only TDD tests I've seen in either project are related to the language
specs -- and there the specs were written first.

Agile doesn't simply mean shorter release cycles, although in both articles
that's how its used. Iterative waterfall methods result in shorter release
cycles.

The key diffs to know the difference: 1) Do you get requirements up-front for
a release cycle? The length of the cycle doesn't matter. Can be 1 week or 6
months. 2) Do you have specs for the major features? 3) Do you design up front
or do you write tests first? 4) Do you have a big test pass before release?

These are the main diffs in the way waterfall and agile manifests.

Honestly, the only people I know who use Agile are hacks. Every time I've seen
anyone try to demonstrate it, it is a disaster. IMO, its the most embarrassing
movement in software engineering.

~~~
newt
I don't think that you know agile that well. If you define agile as "hacks"
then it's no surprise that only hacks will match your definition of agile.

"requirements for a (short) release cycle" is a good description for a scrum
sprint backlog. Scrum or agile does not say that you can't have "Specs,
designs, and dot releases" in some form if you need them.

~~~
kenjackson
I use these specific definitions for agile as they are the ones that come up
as real differentiators in practice. Of course Agile by itself is virtually a
meaningless term that often simply means, "we're going to release more often",
but really doesn't say anything about the SLC per se.

------
jay_kyburz
I've always used the word "Agile" to describe a project management style that
can move quickly and respond to change.

Becoming a certified scrum master and rigidly following the rules of SCRUM
seems counter to this. Isn't the first line of the manifesto "Individuals and
interactions over processes and tools"

Having said this, I should add that I believe even agile teams require strong
leaders with a clear vision for the product, I'm not a fan of democratic
software development.

------
RodgerTheGreat
This premise is a false dichotomy. Agile and the Waterfall development cycle
are not binary opposites. If you take a waterfall and break it up into a
number of smaller milestones, you start to get something that resembles the
bare bones of Agile. If you look at a single Agile sprint, you will see a
miniature Waterfall. Finding the balance point between these extremes for a
project and a team is what makes "agile" work.

~~~
zb
No, no, no. What you're describing is Barry Boehm's Spiral Model from the
early 1980s. If you look at a single Agile sprint you should _not_ see a
miniature waterfall. In Agile, activities like requirements, design, coding
and testing happen _at the same time_. This is the essence of Agile, and what
separates it from the Spiral that came before.

~~~
kenjackson
How is it possible that you get requirements and code at the same time? Like I
literally start writing code, while at the same time have a meeting with the
customer to figure out if they want an accounting system or a CMS?

~~~
zb
Because the customer has _no freaking idea_ what the requirements are at the
start of the project. That's always been the failure of Waterfall. You've
never been writing code and suddenly thought of something that needed to be
added to (or removed from) the system? Seriously?

~~~
kenjackson
I'm not sure how what you said is incompatible with waterfall/spiral. You can
certainly add/remove/change requirements, but you don't start coding until you
have at least a first pass on some subset of requirements.

~~~
Ramone
Waterfall doesn't have multiple passes. You have to have all your requirements
before you move on to design. And that has to be complete before you move on
to implementation. That's why they use the waterfall metaphor, because
waterfalls don't flow back up. And if waterfall seems completely braindead
now, keep in mind that the old software guys used to be hardware guys, and it
makes much more sense for hardware.

You're right about Spiral though... Spiral is iterative, so its much more
compatible.

~~~
newt
_Waterfall doesn't have multiple passes_

the only way that it can not have multiple passes is if the program is thrown
away after V1.0. Any successfully program will be maintained and extended.

------
mkramlich
I hit upon a pretty simple process a couple decades ago and it seems to work
pretty well and doesn't require any fancy books, titles, lingo, paradigms,
papers, etc.:

1\. observe/listen/read/question/collect-information

2\. think (analyze, hypothesize, decide, etc.)

3\. code (techically it is 'do', and the actual action varies by field,
context and goal)

4\. goto 1

~~~
newt
Nice. What percentage unit test coverage do you generally get? How do you deal
with regressions introduced by bug-fixes? With technical debt? With
requirements change and scope creep?

How much refactoring do you do? How big a team does this approach scale to?

------
jaxtapose
Agile has a similar problem to Waterfall.

Business is a bunch of cheap pricks who don't understand the value of doing
things right.

