Comment by DanielBMarkham | Hacker News Reader

Comment by DanielBMarkham | Hacker News Reader

Parent Full thread

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...

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com