Agile Methodologies; New age airy-fairyness or actually serious?

[nfoote]

Now, I'm a Java Dev looking for new contracts at the moment and invariably theres a whole pile of agency ads out there that list things like "Agile", "XP", "Pair programming" and "SCRUM" right alongside actual technical requirements like, oh I dont know, Java!

I do actually agree with most of the core ideas behind Agile, things like continuous integration, high test coverage, TDD (in non-exploratory/prototyping cases) and always having a working system by the end of each section of work.

However does it really need all these airy-fairy terms like Scrum Master (ie Project Manager), Bullpen (ie, that bit of floorspace over there) and Sprint (well I dont what else you'd call a section of work but I know I can't run, let alone sprint, for a whole two weeks!). Sometimes seems like a lot of "making up stupid unrelated names for things that are actually pretty simple to make it sound like you've got some new idea that nobody else could have possibly thought of before".

While I've never worked in a strict Agile environment before I have worked with teams that pretty much take the best/most useful bits of Agile and then, you won't believe this ... get on with the work (without the need to pass some speaking-stick around before they can talk about what they're doing/having trouble with).

What do people that do work in strict XP/SCUM offices find some pleasing about it?

One last bugbear thats just got to me is the whole "pair programming" thing. One agency job advert actually says the candidate will need to pass a pair programming exercise. What in the world is that??? How is Agile's Pair Programming any different to any normal developer going over to a college's desk and them sitting as a pair for 10min/30min/1hr/4hrs/8hrs/a whole week until together they solve a difficult problem? I've never worked anywhere that stipulated problems need to be solved on your own. Its fairly basic human nature and I'm pretty sure the concept of "two heads are better than one" has been round for a few thousand years longer than fancy pants Agile!

*Groan* I've even just read the opening line of Wikipedia's entry on Pair Programming; "The person typing is called the driver. The person reviewing the code is called the observer (or navigator)" ... why, why, why? How about "The guy what is typing" and "The guy what isn't". K.I.S.S.

[Dearnla]

*Groan* I've even just read the opening line of Wikipedia's entry on Pair Programming; "The person typing is called the driver. The person reviewing the code is called the observer (or navigator)" ... why, why, why? How about "The guy what is typing" and "The guy what isn't". K.I.S.S.

Tell them you used to fly Mosquitos during the war, and followed that methodology exactly - you flew, the Nav navigated. No??

Or simply adjust your cv to add the appropriate buzzwords in to your previous roles, as appropriate. And swot up to enable you to drop them into the interviews as well.

[VectraMan]

If I'd ever suggested to any of the people I've worked for that we needed to hire twice as many developers, but to do the same amount of work, they'd have first laughed, then looked concened for my mental health, before finally starting to look for my replacement.

I like the idea of continous integration, staying close to releasable versions etc. But I can't imagine full on Agile is anything but self-indulgence.

I can recommend a book: The Art of Agile Development by Shore & Warden. It raises my Samsung monitor to the perfect height.

[d000hg]

I don't buy into the idea you must treat Agile as some magic process, and to miss any part invalidates the entire thing.

But on the other hand I don't see a major reason not to use all the terminology and so on if it doesn't raise specific problems. It seems to be a fairly well proven approach.
And of course using the proper terms means it's much easier to standardise... how would you tell from a CV if they know Agile if everyone has their own definition.

If I'd ever suggested to any of the people I've worked for that we needed to hire twice as many developers, but to do the same amount of work, they'd have first laughed, then looked concened for my mental health, before finally starting to look for my replacement.

Where does agile say you need 2X as many people? Are you thinking of pair-programming because it sounds like you misunderstand the point, if you got that impression.

[d000hg]

*Groan* I've even just read the opening line of Wikipedia's entry on Pair Programming; "The person typing is called the driver. The person reviewing the code is called the observer (or navigator)" ... why, why, why? How about "The guy what is typing" and "The guy what isn't". K.I.S.S.

On that basis we would have "the guy who flies the plane" and "the guy who sits next to the guy who flies the plane".

[VectraMan]

Where does agile say you need 2X as many people? Are you thinking of pair-programming because it sounds like you misunderstand the point, if you got that impression.

Go read the thread again. The OP's last two paragraphs are about pair programming.

I admit I find it hard to seperate out the various bits of new-age airy-fairiness and use the terms correctly. Partly because it's incredibly uninteresting, but also because I could get a lot of useful programming done in the time it would take me to learn about it. I should probably read the book, though that would mean finding another book to use as a monitor stand. I have one on Design Patterns somehwere - which is another good case in point. Giving new terminology to something that people have been doing for years, which everybody has to learn, because just like Agile, it's more important to know the right words than it is to be able to do it.

[thunderlizard]

As usual Steve Yegge is nice and level headed on the subject:
Stevey's Blog Rants: Good Agile, Bad Agile

[TestMangler]

I got a senoir management memo today to say that the 'Hot-Spots' meeting was cancelled and we would now have a 'firehouse'........what a load of b0110x

[d000hg]

Go read the thread again. The OP's last two paragraphs are about pair programming.

PP doesn't say you need 2X as many people.

[d000hg]

Giving new terminology to something that people have been doing for years, which everybody has to learn, because just like Agile, it's more important to know the right words than it is to be able to do it.

Look at any other branch of engineering or skilled trade... the 'right words' are how you make sure two people mean the same thing and do things in a consistent way. Most developers would NOT automatically use a good example of a factory/singleton/whatever unless they'd read a standard definition... they'd cobble together something similar but less polished and probably it'd be slightly different each time. Wastes everybody's time.

Plus, it's much easier for documentation... you just say "class X is a singleton", no need to explain what this means.