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

[MrGrunge]

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

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

Documentation and Progress Reporting is useful but only within limits. If the code is twaddle, there is bad (or no) design, bad partitioning etc; then Documentation and Progress Reporting etc, is meaningless.

This happens too often in Agile projects, hence Fragile, because it all breaks too easily.

[MrGrunge]

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

Can one 'know much' about something as non-tangible as Agile?

Out of 1 XP project and 5 Agile projects, I can say I have some experience of what its about. However I am not an expert and don't aspire to be so.

[d000hg]

Agile promotes continuous refactoring (doesn't it?), so that you don't end up with fragility. If developers hack the code instead and/or management consider refactoring a luxury, then they're doing it wrong and the codebase will end up a big mess. The whole foundation of iterations and not designing too far ahead is you re-design it as you go, not implement layer upon layer of hacks each time round. Bad developers will ruin things whatever process you use.

And even if the codebase is crap, what it's supposed to do should still be documented. And I can't see any argument not to report progress on a regular basis - that's certainly not an Agile-specific thing - unless we have different definitions of what progress reporting means, which is possible.

[d000hg]

Can one 'know much' about something as non-tangible as Agile?

Agile, XP and other methodologies are pretty tangible in that they can be described formally and you can easily evaluate if a project is following one of them. All these buzzwords and so on are what enable this to be the case... though personally I don't favour an 'off the shelf' approach to picking and using a methodology, being able to explain to other developers and techies what we do is much easier having these around as frames of reference.

[MrGrunge]

Agile promotes continuous refactoring (doesn't it?), so that you don't end up with fragility. If developers hack the code instead and/or management consider refactoring a luxury, then they're doing it wrong and the codebase will end up a big mess. The whole foundation of iterations and not designing too far ahead is you re-design it as you go, not implement layer upon layer of hacks each time round. Bad developers will ruin things whatever process you use.

And even if the codebase is crap, what it's supposed to do should still be documented. And I can't see any argument not to report progress on a regular basis - that's certainly not an Agile-specific thing - unless we have different definitions of what progress reporting means, which is possible.

Yes this is fine and works for smallish projects, but bigger more complex ones tend to require more upfront design. Without sufficient robustness from critical parts, integration becomes a waste of effort i.e. if the interfaces of the integrating parts are only going to be mocked, meaningfull Unit Testing is just delayed.

Bad developers are a pain, but bad managers and bad architects are worse. Process and Methodology does not address these problems.

Documenting what the code/system should do is important. How often do you see that in sufficient detail? I see it for small-scale easy stuff, but not complex systems i.e. life as it is and life as it should be.

Once the code is scrunged-up, time is best spent fixing it up, as best as the bean-counters will allow. Once that is done, then just maybe there is something worth reporting and documenting further.

[MrGrunge]

I don't favour an 'off the shelf' approach to picking and using a methodology, being able to explain to other developers and techies what we do is much easier having these around as frames of reference.

All I see and hear about now is Agile, Agile, Agile etc. Its almost like lemmings jumping of a cliff.

I expect it to be replaced by some other acronym-speak somewhere down the road.

Two things seemingly never change in software development. 1) People are not good at managing requirements 2) People always underestimate the technical complexities involved. Is that a methodology, process etc or just stark reality ?

[doodab]

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

Is anyone going to point out that it's a method?

[Svalbaard]

New age airy-fairyness? Definately. Serious? Well, there is no harm being conversant with the lingo and general way Agile methods are used - as they do have their place on certain types of projects. They have no place being used as the main methodology for large complex projects however.

In my experience a lot of PMOs miss the point of Agile methods and naturally try to sell them on hype as a magic wand that will guarantee that a project will deliver quicker - but not really understanding that it is very rarely the method chosen that prevents a project delivering on schedule - but the lack of good governance and heavy lifting done upfront in terms of requirements analysis and controlled detailed design. But of course, no tangable progress or deliverables in terms of benefits come from these stages per se, so quite often these stages are seen as a waste of time over a JFDI approach.

I see that these fads do make the publishers of books plenty of money though - so I might write one of my own.

[minestrone]

I have found that companies now cling to agile because the process can be controled and that is often because they have been battling for years, and failing, to control the software they create.

I have made my peace with agile now, I am working with a mob who took me in for an emergency meeting because I was 17 hours behind on the plan after 8 weeks of work. Nearly all projects I have worked with have been agile, I was doing daily stand up meetings in 1998, I just cannot get my head round the micromanagement at clientco.

And it's not a silver bullet as the Chrysler Comprehensive Compensation project showed. I do like to mention that when getting the 'agile can save the universe' lecture you get every so often at work from some agile crazed middle manager.

"what is that" they say

"well it was the first agile project"

"oh I never knew that"

"it was a disater"

"oh"

And if nick you want to try and say agile and XP are 2 different things I will quote Martin Fowler "The term 'agile' refers to a philosophy of software development. Under this broad umbrella sits many more specific approaches such as Extreme Programming'"

I think Hani Suleiman sums up my thoughts on Agile...

Maybe NSFW

The BileBlog » Blog Archive » The death of Agile

[d000hg]

What's the micromanagement at your client got to do with Agile? An insecure manager/PM will be equally useless whatever methodology they use.

I think Agile is maybe formally used to describe a higher level way of thinking about software development, but by now an actual Agile methodology exists as well. All the stuff with stakeholders and scrum and sprints forms quite a comprehensive methodology after all.
But as with all non-technical things, there are no rules, only ideas and peoples' interpretations of them.