Book on Agile

[swamp]

Agile Software Development by Robert C Martin is ok. The examples go on a bit (I didn't read the whole book) but it tells you the agile principles.

[Bumfluff]

My current gig is supposed to be Agile and nothing has been achieved in the 2.5months Ive been here, specs on are the back of a fag packet no planning at all, seems to lack direction. Prior gig it was very nailed down, decent planning etc at the time I didnt like it being so anal but I miss it a bit now. Agile is also referred to as cowboy development. Im sure it works in some contexts though.

[darmstadt]

We're currently using Agile here on this project and I had never heard of it before (I'm not a developer) and its strange to say the least. The daily scrum is a bit of a pain in the bottom as we have it just before lunch and normally I haven't done anything by then so have to make up tulip. It all seems a bit 'hang by your fingertips' type of project management

[Jason]

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.

[Bumfluff]

We're currently using Agile here on this project and I had never heard of it before (I'm not a developer) and its strange to say the least. The daily scrum is a bit of a pain in the bottom as we have it just before lunch and normally I haven't done anything by then so have to make up tulip. It all seems a bit 'hang by your fingertips' type of project management

My daily scrum is at 9pm night due client being based in San Fran and Auz, its a real pain in the butt, 'today I looked at cuk and tomorrow urrmmm I will do the same'

[Jaws]

Agile Principles, Patterns and Practices in c# by Robert C Martin is a good book, obviously more developer oriented.

I've used most of the different practices but it generally varies from project to project here, most consistently using TDD & continuous integration.

[DodgyAgent]

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.

The problem you prop heads have is that you like everything neatly tied up and done according to your own terms, a nice spec that you can take away and play with for 6 months without any user interference. something that pleases your own technical ideals even though by the time it is "delivered" is totally inappropriate. Agile requires something called "communication skills" and attempts to understand and accommodate the exact requirements of the user.

[Bumfluff]

The problem you prop heads have is that you like everything neatly tied up and done according to your own terms, a nice spec that you can take away and play with for 6 months without any user interference. something that pleases your own technical ideals even though by the time it is "delivered" is totally inappropriate. Agile requires something called "communication skills" and attempts to understand and accommodate the exact requirements of the user.

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

[DodgyAgent]

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

Fair point. I am simply countering the "set in my own ways" dinosaurs

[Jason]

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.