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

[rd409]

The biggest advantage of being AGILE is "It adds up few tenners on my daily rate". That's it pretty much. It has got nothing new apart from the jargons, which I can blag about during any interview, and make the client believe that he knows so little than me

[thunderlizard]

"The word Agile has worked hard for 10 years. I can forgive it for being knackered"

-Ward Cunningham on Twitter yesterday.

(OK, strictly speaking he said "tired" not "knackered").

[MrGrunge]

The title of the thread demonstrates the problem, Agile is not a methodology, any more than unit testing, users working alongside developers, peer reviews, whiteboard design, CRC cards are methodologies. Any job advert that asks for Agile methodologies has clearly not doing agile software development. Agile when used correctly and appropriately is very effective and more effective than most other approaches, but it does have limitations.




Then what is happening is not following the Agile manifesto then, Agile projects (run as Agile projects) the opposite is true.

If Agile is a manifesto rather than a process/methodology/way of thinking/whatever; then is it not open to interpretation, lacking in definition, and likely to become a political manifesto/quasi-religious cult (consciously or unconsciously on behalf of the participants)? i.e. non defined Agility can easily become an instrument of mis-management in the same manner as much as any dogma in any other walk of life.

Although not particularly moved one way or the other, there do seem to be numerous interpretations as to what Agility is. Personally, I don't really have an opinion as to what it is, and view it as more or less as a phenomena of our times, in the same way as baseball hats became an ever expanding fashion accessory about 20 years ago.

Yes that is the Agile approach

If 'pragmatic' means not converting double to BigDecimal in an ecommerce app without folk screaming etc (as I have recently witnessed); then I'm not sure of the value.

You take from Agile which is appropriate for your project, the biggest factor on what you can and cannot use from Agile is the organisation and processes you have to work with.
.

I largely agree with this.

I think like many others in the industry you have totally misunderstood what Agile is about.

Then prey inform me as to what 'Agile' is about. I am largely neutral about what 'Agile' is, and don't concern myself with Agility a whole lot, other than its part of the general banner in about 80% of the projects that I work on now, I merely report on what I have experienced in folks Agile projects, almost all of which do not meet their objectives, but do exhibit some interesting activities and artifacts from time to time.

One aspect that I do like is where a small number of complementary folk can work together in a fairly chaotic and explorative way. This does depend on folk being complementary i.e. different folk bring slightly different ingredients to the pie and co-operate in the cooking of the meal. However this seems to be rare for one reason or another e.g. too many folk involved generally to enable such a setup, or political animals view Agility as a way to throw their weight about ( a bit like a hippo shifting dingleberries of its posterior with its tail.)

[rollingergrund]

The title of the thread demonstrates the problem, Agile is not a methodology, any more than unit testing, users working alongside developers, peer reviews, whiteboard design, CRC cards are methodologies. Any job advert that asks for Agile methodologies has clearly not doing agile software development. Agile when used correctly and appropriately is very effective and more effective than most other approaches, but it does have limitations.

Agile usually becomes Fragile i.e. code breaks all over the place, stuff doesn't work

Then what is happening is not following the Agile manifesto then, Agile projects (run as Agile projects) the opposite is true.

folk do what is 'pragmatic'

Yes that is the Agile approach

i.e. ony the easy-peasy parts and shelve the necessary difficult parts; all in search of silver bullet technology mega-futz.

You take from Agile which is appropriate for your project, the biggest factor on what you can and cannot use from Agile is the organisation and processes you have to work with.

[quote
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.)
[/QUOTE]

I think like many others in the industry you have totally misunderstood what Agile is about.

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

[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

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

[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?

[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 ?

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

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

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

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

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

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