

I Hate the Agile Manifesto - DanielBMarkham
http://www.whattofix.com/blog/archives/2008/08/okay_i_hate_the.php

======
ajross
Honestly, I think this is exactly backwards. The voodoo juice in "agile" comes
from the mindset, and _not_ the specific practices. The mindset is
encapsulated pretty well by the manifesto, IMHO. Could someone write a better
one? Maybe.

But if you want to know what agile is all about, read the manifesto. Decades
of experience in XP, *DD, AUP, etc... isn't going to teach you much about the
"why" of those paradigms. If I were an agile proponent (and I'm really not)
interviewing a candidate, I'd want to know that they can explain the handful
of ideas in the manifesto. Process stuff is something any monkey can
implement.

~~~
DanielBMarkham
Whoa horsey. Nobody is arguing specific practices here. I'm arguing that feel-
good marketing bleck doesn't make a project run. In fact, it confuses more
than it helps.

Want a good checklist of what agile is? Try
[http://www.whattofix.com/blog/archives/2008/04/the_agile_che...](http://www.whattofix.com/blog/archives/2008/04/the_agile_check.php)

Or:

    
    
        * Adapt - Always ask yourself what is wrong and what you need to do to fix it. If you continuously communicate to identify problems and fix them, I believe that in a normal world you will do the following things that I can observe:
    
        * Time-Box - You have a fixed, immutable time-box in which you deliver tested changes (either code, documents, processes, beans, whatever) that be demonstrated
    
        * Togetherness - The closer everybody is, the better. Co-located, non-cubicle, non-office spaces are best. Highly matrixed, separated teams are worst.
    
        * Value - You have a clear way of determining the most valueable thing to do each iteration. Business Owners give you business value. Technical Owners give you architectural value.
    
        * Ownership - The team, and only the team, owns its estimates. Outside factors are considered and can be communicated, but at the end of the day the team has the power to determine the amount and type of work it can take on for each iteration.
    
        * Forecast - Being agile and empirical does not preclude precictability or forecasting. In fact, the value of agile teams is their ability to take highly-changing environments and put some kind of predictable forecastable order in them.

~~~
ajross
Horsey?

I don't much disagree with any of that. I might quibble with a few things (I'm
not sure that "forecast" is really a central theme in most schemes, lots of
very successful, nominatively "agile" development gets by without much of a
timetable), but that's not particularly at issue. Your list looks good to me.

But it also looks like a manifesto. And that's fine. So maybe your point is
that you like your manifesto better than the official one? I like the poetry
of the original better, but yours seems good too.

But I don't understand the idea of "feel-good marketing bleck". The points of
the original look awfully profound to me. I think you're being too hard on it
here. If you like concrete guidelines more than statements of purpose, feel
free. Just don't throw tomatoes at those of us who prefer the poetry.

~~~
DanielBMarkham
I think you miss my point.

I'm not crazy about manfiestos or checklists period. If you made me pick
something, it'd just be "Adapt" But if you insist on having some list of
statements that define what agile means to you, at least pick something that
is measurable and doesn't leave you in a confused quandry.

Valuing one thing over another has the impression that it is giving you
information, when in fact it's leaving things more murky. If it's all
relative, when would the other thing hold true? Why must there be tension
between the two things?

People come to me all the time because they don't understand that the
manifesto is empty of meaning. Instead they think there is something profound
there. They say things like "we should eliminate all documentation because
it's in the manifesto" or "we value people over contracts, so offshoring can't
work"

But the manifesto says no such thing. In fact, it doesn't give much practical
advice at all. It's just feel good, mom and apple pie stuff.

~~~
festivusr
I'd take the manifesto over any stack of "Agile Programming with Blub" books
any day, or the advice of any Agile Coach, for that matter.

Each statement is giving you information. "When faced with one of these two
things to concentrate on, we suggest you concentrate on the first one." That
information might be obvious to you as an expert, but is non-obvious to some
people, including many decision makers that don't develop software on a day-
to-day basis.

Is it an exact recipe to follow? Nope, but neither is development an exact
science, or something you can do by rote following of a checklist. Which is
exactly the point of the first item in the manifesto, incidentally.

~~~
DanielBMarkham
You've lost me, festivusr.

It's not an exact recipe to follow. This we can agree on. We don't need
recipes.

The quote I think you're looking for is "That is, while there is value in the
items on the right, we value the items on the left more. "

Which tells me exactly diddly-squat. In fact, there are times that the things
on the right are critically important; vital pieces without which the project
will surely fail. How much more value could you put on something than that?

How about "Working software over comprehensive documentation"? Ever work on a
project at the PMO level? How about doing a build-buy decision? Or perhaps
splitting up a couple billion in work into small pieces for vendors to bid on?
There are a zillion ways working software is a bullshit way to value anything.
Working software is great. But it's not the opposite of documentation. For
each bit less of documentation, you don't get a little more working software.
The topics are not opposites and inversely proportional to each other.

You want to start a marketing campaign? Sell a lot of books, do a lot of
public speaking engagments, all of that? Then come out with something like
"Contract with America" or "The Agile Manifesto" or "The Swedish Bikini Team"
-- anything that gets your point across easily and memorably. The Manifesto
does that.

So now that you've bought the freaking cereal, it's time to put away the box
and actually get to eating the dang stuff. And guess what? All of that sales
stuff on the box? It's just sales stuff. The real stuff requires you to think
and participate, not have happy feelings about the great revolution you're
part of.

I've ranted enough. Seem like a nice person fest. Have fun with the manifesto
and don't listen to any of those books or coaches. Probably just confuse you
anyway.

I'm done.

~~~
festivusr
I guess we've lost each other, then. In my opinion the ideas in the manifesto
are the best part of anything that has had the agile label slapped on it. I
guess you don't get anything out of them, but I'm not sure why not. If you
want to try to apply them to things that they obviously don't apply to, like
writing RFPs, then yeah, they don't make any sense.

In many cases you DO have a direct choice on which of the items (column A or
B) to focus your efforts on. You can tell your developers to focus on writing
code, or write control gate documentation. You can spend your time as a
manager working on procuring the next new silver bullet tool, or on hiring,
retaining, and working with top talent. Now there's nothing that says you
can't do both, but you certainly have a choice on how much time and effort to
spend on each.

As far as a sales slogan goes, yes, the manifesto is the headliner for the
books and coaches and everything else that costs money in the writing and
consulting world that is selling methodology silver bullets. But you can use
the ideas in the manifesto without spending one thin dime on any of that
stuff.

