One of the problems I have with the whole agile development is that it seems to flirt around the edges of being well defined without ever really getting there
What people don't always get straight away is that Agile is NOT a methodology its just a framework, and basically you choose a methodology like Scrum / Lean or XP (extreme programming) from within the Agile family so to say.

Methodologies like SCRUM are actually well defined, that link i posted probably wasn't the best to give you a clear definition though.

It is also worth saying these kind of methodologies are not for individuals or small development teams and if you work in one of these environments then Agile can look very strange to you.

If you work in a Software house where you sell software to business customers then Agile can do a great job making you more reactive to your customers, and if done well can definitely improve your software delivery and product quality.

(ok, so the whole post was about not telegraphing those final two words, but I really do doubt whether agile is more fluff or substance.)
Having worked in an Agile environment i can assure you that if done properly it can work well.

It can also work badly as well if badly implemented, if the development manager doesn't understand it very well or if the team is not experienced enough.

At my last place of work we moved completely agile, first to SCRUM and then to LEAN agile, and we did it in 7 separate development teams

So it was a big place, 7 dev teams all with around 6 developers + 2 testers.

Not all the teams implemented Agile well, and the teams that were inexperienced really struggled in particular with SCRUM which due to the developers not knowing the product meant that planning meeting were at times lasting an entire day for one of the teams!!! (i am not kidding)

If you have an experienced development team working on a product they know (as in Kevin's case), then this reduces these meetings considerably and makes SCRUM workable.

LEAN Agile as a methodology removes many of the meetings described in SCRUM, and in fact it uses principles of lean manufacturing. You basically create a backlog BUT you only clearly size and define the stuff you are about to work on, everything else you spend less time on as it is to far away.

As you pick jobs up you do a task breakdown into task developers can pick up, and share them around the team.

Also you have don't have a fixed plan, you decide on what to do next on a day to day basis as the team finish the last job. You do have a plan (or backlog which should define your whole project) BUT only the over all deliverable NOT what is done when.

To be fair it is a bit more complicated than this as you can have architecture tasks, and if you have dependencies then the Development manager will need make sure that this is reflected in the backlog.

It is a bigger subject then this post to fully describe the process

Out of the 7 teams at my last place i would say 5 of them in the end implemented Agile well, the other 2 teams should have never been moved to an agile environment in my opinion.

Agile and its flavours can work really well but as with any other methodologies;

- firstly it needs to fit the problem you are trying to solve

- secondly you need to implement it well.