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

[Dark Black]

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.

Totally agree, especially the bit about Design Patterns. At a previous gig I used to sit opposite some self important geek who was forever going on about pattern A or pattern B. Turned out to be just the usual common sense stuff I'd been using for years (without needing a book to tell me how to)...

[MrGrunge]

Agile usually becomes Fragile i.e. code breaks all over the place, stuff doesn't work, folk do what is 'pragmatic' i.e. ony the easy-peasy parts and shelve the necessary difficult parts; all in search of silver bullet technology mega-futz.

There are some upsides like CI, Unit Testing, attention of business users (because they can see what the dirty IT geeky folk are doing - a bit more.)

Works reasonably effectively where the scope, size and technical complexity are small along with the number of involved bodies. Any of these factors increases just a tad and Agile is unlikely to generate anything terribly useful.

Ultimately its just another stoopid management speak acronym for 'you'd better get it working or I'll bust your face.'

A lot of stoopid buzzwords - Burndown chart - whats wrong with a Gant chart from 25 years ago? Sprint - any difference from an iteration from the dawn of OO? Mind you I remeber when folk thought OO was twaddle and wanted to code everything in C.

It all goes into the washing machine and gets spat out every now and then with new silly buzzwords and Splodge-ologies under a new name.
Just my take.

[d000hg]

If Agile normally cocks things up, are you claiming the traditional alternative (waterfall) is better, or as bad, or worse?

Even though I'm not a massive Agile fan, I read enough about it to see that most people criticising it are fairly ignorant what it means... as are management who want to use it. "It doesn't require any planning", "We don't have to do any documentation", etc.

Lots of it is common sense in hindsight... but it's common sense accumulated after a lot of research because the majority of developers don't know all these things. Like much of useful education, it's things you can figure out as you go condensed so you don't have to spend years learning it. One developer on a team who does all these things is going to be pulled down by the other 9 who think bug-tracking and source control are "buzzwords".

[HairyArsedBloke]

There are some upsides like CI, Unit Testing, attention of business users (because they can see what the dirty IT geeky folk are doing - a bit more.)

I have moved from being a techie to the other side, but I still do loads (too much) of my own development.

I do not do any formal agile methods. However, I do like TDD with DDD. I think that close involvement of the business and development staff on a continuous basis is key to successful delivery.

[MrGrunge]

If Agile normally cocks things up, are you claiming the traditional alternative (waterfall) is better, or as bad, or worse?

Basically Agile is applied OO with some technology support and greater business user involvement. This is an upside in small scale development, but tends to diminish in complex systems.

Most (but not all) end-users/business folk cant get to grips with technical complexity and can over-simplify things to ridiculous levels.

Sometimes its better to do more upfront design and analysis. Also sometimes a lot of technical requirements need to be addressed (for this Agile is usually useless - because it cant be time-boxed easily, done in pair-programming instantly etc.) Once some of these hurdles have been overcome, in complex applications, I think there is a place for Agility, but not before.

The problem that I see with Agile is most folk from Managers to business folk to a lot of devs and others; all approach it as some kind of bizarre religion.

[MrGrunge]

I have moved from being a techie to the other side, but I still do loads (too much) of my own development.

I do not do any formal agile methods. However, I do like TDD with DDD. I think that close involvement of the business and development staff on a continuous basis is key to successful delivery.

This is one important key, but its not the only one. All the agile projects that I work on all lack sufficient Technical vision (because its unimportant in 'Business' eyes.)

However, this is twaddle. The technology is damm complicated now, is getting more complex, and will continue to do so probably for at least as long as I will work in IT. Technologies like Parallel Processing are not too far away now e.g. concurrency is available even in highly 'Agile' technologies like Scala now.

[MrGrunge]

Even though I'm not a massive Agile fan, I read enough about it to see that most people criticising it are fairly ignorant what it means... as are management who want to use it. "It doesn't require any planning", "We don't have to do any documentation", etc.

Sprint Planning - its always in the mix; for good, bad or otherwise. Demands for documentation, filling in silly progress reports, along with slightly more sensible artifacts like Javadoc, Code coverage tooling; all abounds in Agile projects - and tends to get lost knee-deep in this type of stuff.

Lack of Technical vision is the biggest hurdle in Agile projects that I see (regularly), the rest they could get by with if they got to grips with the technicalities.

[d000hg]

The problem that I see with Agile is most folk from Managers to business folk to a lot of devs and others; all approach it as some kind of bizarre religion.

I'd agree... but that's no different from any other entrenched Process.

Sprint Planning - its always in the mix; for good, bad or otherwise. Demands for documentation, filling in silly progress reports, along with slightly more sensible artifacts like Javadoc, Code coverage tooling; all abounds in Agile projects - and tends to get lost knee-deep in this type of stuff.

Documentation & progress reports aren't silly, or areas Agile is normally criticised for too much of, normally the opposite in fact.

[Muttley08]

Basically Agile is applied OO with some technology support and greater business user involvement. This is an upside in small scale development, but tends to diminish in complex systems.

Most (but not all) end-users/business folk cant get to grips with technical complexity and can over-simplify things to ridiculous levels.

Sometimes its better to do more upfront design and analysis. Also sometimes a lot of technical requirements need to be addressed (for this Agile is usually useless - because it cant be time-boxed easily, done in pair-programming instantly etc.) Once some of these hurdles have been overcome, in complex applications, I think there is a place for Agility, but not before.

The problem that I see with Agile is most folk from Managers to business folk to a lot of devs and others; all approach it as some kind of bizarre religion.

You don't know much about it do you really?

[NickFitz]

Is anybody going to point out that about 90% of the things people attribute to "Agile" in this thread aren't really anything to do with Agile, they're from XP?

No?

Nobody?

Thought not...