kasia in a nutshell

Oh, I think agile programming is actually more of a non-methodology that's bound to make your managers nervous. Because incorporating change in your working methods is something that blows up all pre-calculated sheets that managers allways love so much.

And it's not just iterative development but puts in some quite interesting ideas. Of course nothing of it is new - but then, if we won't use old stuff in new combinations, we might still get our ones and zeroes by banging rocks together ...

What really kills Agile and XP for me is that the fans fall into two categories:

1) They're a consultant company that trains people on XP/Agile practices.

2) They're employees of a company that's spent vast amounts of money being trained on Agile practices.

There is a third category which is minor but vocal:

3) The guy who believes everything he reads on the Intarweb. And repeats it.

There is almost nothing in the academic field that says either methodology is actually effective. The only paper written on the subject suffers from all sorts of bias. Personally the whole "letting people volunteer" blows it for me, but Hacknot really goes to town on the thing.

http://www.hacknot.info/hacknot/action/showEntry?eid=50

Will.

Right now, Agile Programming is the method du jour at Amazon. None of its proponents are people who fall into any of Will's three categories. So far it's kinda-sorta working out pretty well for us, but we're just cherry-picking the best parts out of it (daily 15-minute status-update meetings, sticky notes for pending tasks and priorities, etc.) and a big part of it seems to be structuring the sticky-note tasks into such small units that people can pat themselves on the back when they move plenty of stickies from column A to column B.

Personally, I've only gotten a couple of stickies finished and I'm doing things in a different order because the way my team lead decided to break my part up wasn't really how it ended up being naturally broken-up-able (and both my team lead and my manager are pretty cognizant of how I'm working on like 10 "separate" tasks at once right now and making decent progress on all of them), which is pretty much what I expected, but it's still a pretty useful method to keep track of my own time management and voicing my overall concerns and so on. Also, we keep adding sticky notes as time goes on (due to other issues which come up), which we're "not supposed to do" but it just shows how flawed the whole development-on-rails thing is.

Plus, the ideal of "no turf or component ownership" totally falls apart when each of us has totally different skillsets, and we'd be wasting a hell of a lot of time if we were doing it "right" and kept on ping-ponging between different areas.

We're very much doing it as an experiment, in any case, and afterwards we're doing a post-mortem to see what worked and what didn't. My teammates all either agree with me or think that "next time we'll do it right and see how it really works out."

IMO, the agile process is (like all development models) a big cargo cult with a few useful processes buried deep inside. (For example, I don't like XP much - and the fact that all of its proponents have now moved on to wanking about Agile - but pair programming can be pretty useful in limited circumstances.)

People use buzzwords to give the appearance of credibility by means of obfuscation. If no one knows what you’re talking about, you sound smart!

u suck and idk who u r! haha