Reply to: Book on Agile

[NickFitz]

You have pointy hair, and I claim my crisp £5.

Wrong.

Grey hair, if that's any help

[Bumfluff]

The project Im still working on is 'Agile' the manager talks the talk for it but he is a weak leader. 3 months Ive been there I still dont really have a clue what the deadlines are etc, its all back of a fag packet stuff with the occassional keys words thrown in 'Iteration', 'Story board'. I end up wasting half my time reworking stuff because of a last minute change in requirements. I can see the benefits of Agile but IMO for it to be successful the PM needs to be a strong in leadership skills, mine isnt and the whole thing lacks direction.

[Cowboy Bob]

Agile done correctly is an excellent methodology. Unfortunately, like nearly everything in software development, most people seize on any excuse to get sloppy and careless (presumably because it's hard to be a good developer, and most people are lazy or just not very good). It's very easy to misinterpret Agile in such a way as to excuse or even condone such sloppiness, which is why it gets a bad rep.

Having been fortunate enough to use Agile in teams of brilliant people who take pride in doing things well, I can definitely state that the problems aren't in the methodology.

FWIW, Leisa Reichelt's Waterfall Bad, Washing Machine Good is an entertaining view of the application of Agile to IA.

You have pointy hair, and I claim my crisp £5.

[NickFitz]

But what if the user doesnt actually understand / know what he wants ?

What makes you think you do?

[NickFitz]

Whatever book you read it will probably quote the Chrysler 3 Project as the flagship of all Agile projects. What it will not say is that one year after development the project failed and had to be re-written as all the knowledge that had not been documented left when the project manager left the company.

Spend most of my time going to clients to remove Agile and put something proper in. Have never seen a "true" success story on Agile so far.

That was specifically an XP project, which is not necessarily the same thing as Agile - it's just one kind of Agile, and its flaws are widely acknowledged by those who aren't into zealotry over methodologies.

[NickFitz]

I nearly always have a good laugh when I go in to sort out a project that has been using agile.

The problem with agile is most people (who champion it) don't have a clue what it really is.

The agile manifesto says:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Nowhere in the manifesto does it say process, documentation, contracts or plans are unimportant and should not be done!

In fact the manifesto goes on to say:
That is, while there is value in the items on the right, we value the items on the left more.


So when I go in, after the mess that is most peoples version of agile, I put all those things in, but keep the good working practices like test first development, continuous integration, paired development and so on.

Agile done correctly is an excellent methodology. Unfortunately, like nearly everything in software development, most people seize on any excuse to get sloppy and careless (presumably because it's hard to be a good developer, and most people are lazy or just not very good). It's very easy to misinterpret Agile in such a way as to excuse or even condone such sloppiness, which is why it gets a bad rep.

Having been fortunate enough to use Agile in teams of brilliant people who take pride in doing things well, I can definitely state that the problems aren't in the methodology.

FWIW, Leisa Reichelt's Waterfall Bad, Washing Machine Good is an entertaining view of the application of Agile to IA.

[Stan]

The last two posts are the opposite of Agile - having hours of meetings is not agile at all!

Agile is good and works well but you have to do it right instead of just bandying around the word "Agile" (oh god this happens so much) while being decidedly waterfall.

[swamp]

Once had to sit through a set of meetings (or Planning Games) to discuss how long each Agile development 'story' would take. There were often 20 people present and no one had any idea what was going on apart from a couple of team leads who wrote the initial application. After droning on for an hour or two they would ask the developers what the estimate was, whereupon we would hold up a random number between 1 and 5 for the development days it would take. Estimating 3 days was the safest as you wouldn't get asked to explain why your estimate was different from the others, and risk betraying the fact you hadn't got a clue what was going on!

These planning games went on for over a month. Soul destroying.

[someone has my name]

Agile is a hunk of Junk .. worked in an Agile Enviroment for a telecoms company.
Seemed more like passing the PM buck on to the developers.
endless meetings teleconfrences spent more time talking about development than on the actual developement...
most people working there thought the same!

[OverTheHill]

Agile books

I found the following resources useful for understanding what Agile/Scrum is all about:

http://www.crisp.se/henrik.kniberg/S...heTrenches.pdf

http://video.google.com/videoplay?do...44396191025011

[grey_lady]

There's one other aspect to Agile which hasnt been mentioned here,
if you have continuous integration, and you only plan say 2 week iterations as you go along then your not working to an overall deliverable end date which probably doesnt go down with other people in a company.

Does that make sense? example would be a whole team sits down and looks at a prioritised list of features that a business has asked for, breaks it down into tasks and estimates the time for each task (post it notes on a wall normally :-) ) business type bod can see how many hours / units it will take for each task and in discussion with the team will decide which tasks are to be done (depending on how much time the team has available, say 1 full time dev might be productive for 6 hours a day etc)
at that stage no more planning needs to be done until the end of the 2/3 week iteration - good in that the business has a closer relationship with the devs (ideally all sat together) but probably doesnt help the rest of the business with their own planning.

Tis a fad me thinks :-)

[swamp]

Agile isn't a methodology, it's a family of methodologies, a set of principles as such.

XP, Scrum, DSDM are all agile methodologies.

[sumo]

Spend most of my time going to clients to remove Agile and put something proper in.

What's that then?

Seems like DSDM has been pretty successful if the organisation has bought into it. I have only had opportunity to use sections of it with some success.

[configman]

Whatever book you read it will probably quote the Chrysler 3 Project as the flagship of all Agile projects. What it will not say is that one year after development the project failed and had to be re-written as all the knowledge that had not been documented left when the project manager left the company.

Spend most of my time going to clients to remove Agile and put something proper in. Have never seen a "true" success story on Agile so far.

[javalad]

No, because when it comes down to it, the "aspects of agile" that are extremely useful are effectively just plain common sense and not exclusive to agile. That is why it's bollox. Because someone, somewhere has given plain common sense a label, then sold it as a brand. And all the sheep managers who have never seen a line of code or understand how development works in practice, buy into it all hook, line and sinker, spend thousands on "agile" training courses and books, yet never seem to be able to grasp that they've been sold a lemon. It's like selling a tin of air from Scotland for it's health benefits. Just go to Scotland FFS...

Exactly.. I too feel that it is all common sense.... nothing spl about following particular... depending upon the scenario we can do things.. but they give a name and sell it..

most funny thing is advertising a developer role with Agile or scrum as important requirement.. at least it can be a essential for managers but not for developers...