Book on Agile

[Dow Jones]

Not so good

I call it Fr-Agile and I agree with Jason's comments. Agile was meant to replace X(treme) P(rogramming) in some ways, however it is far worse in its approach to problem-solving and gimmicky approach.. A well-documented project is a rarity these days and users are crying out for guidance from PMs and teams that haven't got a clue firstly on what they are doing and secondly - and more importantly - how.

[DodgyAgent]

DodgyAgent,

You will note I was dissing most peoples incorrect application of agile, not agile itself.

You are correct on everything you said. Most developers indeed want to play with the toys.

I specifically like your point on communication skills, however good communication skills include more than just talking.

Good consice and and timely delivered documentation is an example of a communication skill that is required on any project.

The situation you describe is a problem with waterfall projects. This is why I use an iterative and incremental process.

We have to remember the point of a (software development) project is to deliver a system that does what the business needs. It does not matter if it is the best system in the world if it does not meet the needs of the business.

An unstructured project with little or no documentation rarely does that.

Fair point, well said. No more cameo appearences in "land before time" for you jason

[Jason]

Awww. I like Land Before Time. My kids always go crazy when the dinosaurs start singing and dancing.

[Zippy]

The main problem with Agile is that it requires competent, confident software engineers and management.

I have worked on projects where it has been a great success because we had decent people and our customer was in constant communication with the team.
Where I am now however it's all going t!ts up because the clients perception of 'Agile' is that he can change his mind on a whim halfway through an iteration without accepting any of the consequences.

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle is rather good.

[TimberWolf]

I would go agile (or whatever funky term is in vogue) on the prototype and then do it properly when adding bells and whistles to a known and agreed working structure and prototype. This is quicker than a lengthy design phase IMO, flexible and user driven. There’s no way I would attempt to build a complex system from scratch, first time around, by relying on some funky methodology or a team of analysts. The downside to this approach is that it eliminates the need for 90% of staff involved in IT projects.

[Jason]

One of the things I do is train and mentor Cobol and RPG developers, taking them over to J2EE and RUP.

A key point with a big change like that is to avoid a BIG BANG. When an organisation is looking at adopting things like Agile and so on. I always advice adopting in an incremental and iterative style.

Introduce one new thing at a time and give people time to get used to that one new thing.

Reduces the likelyhood of catastrophic failure, and gives people a chance to understand the impact of each new tool and/or working practice.

[Cowboy Bob]

It's all management bollox anyway. The best development methodology is the one that the developers are most comfortable with (and I say that as a lead developer/architect with some management responsibility).

[Cowboy Bob]

One of the things I do is train and mentor Cobol and RPG developers, taking them over to J2EE and RUP.

OMG!!! I've seen first hand what happens when RPGers meet OO concepts and it ain't pretty...

[Jason]

You are right there.. it ain't pretty at all.

Mind you once you get them used to the idea that for instance a Customer object can do things not just be things. They tend to pick it up ok

I have had a few people who just could not get it though.. Those people who never used PCs but still use IBM InfoWindow terminals.

The hardest bit for some of those was double clicking. hehe

[Jason]

Cowboy Bob,

You are partially right. Although the developers being comfortable is very important, so is documentation, including good comments. So the poor developer who takes over 3 years down the line has a chance at understanding WTF is going on.

Also the conversation has moved beyond just development methodologies. Talking about software project delivery methodologies.

I think a few of the agile things are good though for development. Such as test first development. I have found that in practice this means less time spent debugging usually helps produce much more robust code. Continuous integration means that you know when the whole thing is broken, and when it all works together, rather than as I have seen in the past, waiting till 6 months or more of unit testing has been done, and then when the first deliverable is due, finding the thing does not work as a whole.

It is way to easy to dismiss everything as management bollocks. Some of the aspects of agile are extreemly useful