
Agile is the new Waterfall  - nreece
http://blogs.agilefaqs.com/2009/04/29/agile-as-practiced-today-is-the-new-waterfall/
======
DanielBMarkham
Pretty good.

Nice observation that organizations are simply taking the old command and
control and factory mentality and trying to make Agile fit into it. But, of
course, it's not vague "organizations" that do this, it's all of us. As
technical people, we naturally drift towards wanting to define more and more
exactly what something is -- we want to program the people. We think that by
continuing to define exactly what is agile that we're helping more than
harming.

I also take issue with the discussion at the beginning that pits "Software
Engineering" versus Agile. This is broilerplate agilista bullshit. If you're
converting a conversation into something useful you're using Engineering
techniques. That's the whole definition of Engineering - moving from spec to
value in some kind of organized way. And that way can be formal, informal,
conversation-based, etc. Duh. Now what you might _think_ of as heavy
engineering is a different subject -- but those are just deployed flavors, not
the true thing. You can't argue that agile is cool but the way organizations
are doing it suck without (hopefully) realizing that software engineering is
_also_ cool but just done in a really sucky way at times by those same
organizations. It's the same difference. So I think making this false choice
shows a real immaturity/lack of deep applied knowledge on the part of the
presenter.

Maybe it's just me, but I'm also getting tired of seeing that same old
manifesto crap with every agile presentation I see. It's not the Ten
Commandments. Get over it. If you're spending 60 slides to explain what agile
is, then that's your presentation topic, not how agile is being applied. I
guess I liked the conclusion but thought the build-up was overly done.

Overall it was worthwhile to see.

------
gruseom
This part is interesting (from slide 65):

 _Ziv's law - specifications will never be fully understood.

Humphrey's law - the user will never know what they want until after the
system is in production (maybe not even then)

Wegner's lemma - an interactive system can never be fully specified nor can it
ever be fully tested._

... though Google reveals that it was obviously lifted from
[http://jeffsutherland.com/scrum/2007/07/origins-of-
scrum.htm...](http://jeffsutherland.com/scrum/2007/07/origins-of-scrum.html)
(and in neither place are citations given).

------
gruseom
The fact that agile would be overrun by bureaucrats and vendors and thus
turned into the same old bullshit was not only predictable but predicted from
the outset. The new bullshit may not be quite as bad as the old, but it will
take decades if not centuries for the real principles of software development
to be worked out at a macro level.

A big part of the problem is the myth of "organizational change" that is
endlessly propagated by consultants and enthusiasts. I've seen fathomless
amounts of time and energy spent on trying to do this. It is largely poured
down a drain. Inefficient, anticreative organizations don't change, except by
dying. The idea that they can somehow go through an enlightenment experience
and become productive places that are good at making software is extremely
seductive. People are willing to put a lot of money into it and there's a
steady supply of gurus happy to take the other side of that bargain. Note that
the gurus don't produce software themselves, they just talk (at high hourly
rates) about how _you_ should do it. From what I observed (and I saw a lot of
it) this is mostly mutual self-deception.

The way we will get better at software overall is not by "organizational
change" in the places that suck at it, but by starting new organizations (e.g.
startups) to provide new outlets for creative energy, some of which will
succeed and render the old ways obsolete.

Happily, the situation at the individual level is not as gloomy as at the
macro level. We are free to do things differently if we want to.

~~~
DanielBMarkham
I produce software on a regular basis. And I'm also one of those high-priced
gurus you mention.

It's not black or white. Organizations are full of good, intelligent people
who want what's best for both the people and the organization. It's just that
everybody has a different idea of what that is.

I wish it were as simple as "adapt or die" but many times it's "adapt enough
and survive" which means big companies do a little bit of everything.

And it's the agile true believers that are many times behind this make-agile-
just-another-heavy-process movement. Take a look at the various lists for
defining if a team is "really" doing scrum or not. Read up on what some of the
practitioners want to do. The agile community is doing a lot of this to
itself, large organization or not.

So big companies pay us gurus to come in and try to change everything. And
then nobody wants to change. And nobody gets fired if people miss a sprint.
And everybody wants to perfectly define what agile is. And upper management
wants to start tracking what metrics make "good" teams and what make "bad"
agile teams. If you're lucky, you improve productivity by 5-8 percent using
whatever generic agile principles the teams can accept.

That's a winning preposition for everybody. Doesn't feel great, and there is
no break in the clouds with sunlight streaming in and music playing, but from
a cost-benefit perspective it's a worthwhile cause.

Yes, agile is full of wonks preaching TDD that haven't coded in 20 years. Or
analysts with 2 years of experience apply agile with a checklist. But that's
where the movement is at right now -- it's spread from emphasizing delivery to
being a little bit of something for everybody.

I wish it were as simple as you say.

~~~
gruseom
I didn't say it was simple; I said it was mutual self-deception. That being
said, I did find a simple solution: I got out. The effect is comparable to
what I imagine someone would feel if they were cured of athsma and able to
breathe.

~~~
DanielBMarkham
Once again, I don't think it's mutual self-deception. People see that agile
principles work. Some don't understand how it applies to their job. Some,
quite frankly, view agile as a bunch of new age, feel-good crap. In a big
organization, life is about compromises. That can look like self-deception,
but it's not.

I'm not a big corporate guy, even though I work with them, so I understand the
freedom of getting out. When I'm in startup mode I'm about a hundred times
more happy and productive than working in a large group.

But corporations still exist, and people still need to work in them. Some
people _want_ the imagined security that things will not change -- that they
can punch a clock every day and work at the same place for 30 years.

Now you and I know that stability is an illusion, but it's one that people
cling to.

