www.triusinc.com

I don't agree with the points this blogger is making, but I thought others here might be interested in a different take on things.

Here is the blog link:

http://blog.assembla.com/assemblablog/t ... Agile.aspx

Well, this blogger wouldn't be the first person to have that opinion. There is a very good book on the subject. I strongly recommend it.

Agile!: The Good, the Hype and the Ugly - Bertrand Meyer

Here is a description for it from Amazon.

Are you attracted by the promises of agile methods but put off by the fanaticism of many agile texts? Would you like to know which agile techniques work, which ones do not matter much, and which ones will harm your projects? Then you need Agile!: the first exhaustive, objective review of agile principles, techniques and tools.

Agile methods are one of the most important developments in software over the past decades, but also a surprising mix of the best and the worst. Until now every project and developer had to sort out the good ideas from the bad by themselves. This book spares you the pain. It offers both a thorough descriptive presentation of agile techniques and a perceptive analysis of their benefits and limitations.

Agile! serves first as a primer on agile development: one chapter each introduces agile principles, roles, managerial practices, technical practices and artifacts. A separate chapter analyzes the four major agile methods: Extreme Programming, Lean Software, Scrum and Crystal.

The accompanying critical analysis explains what you should retain and discard from agile ideas. It is based on Meyer’s thorough understanding of software engineering, and his extensive personal experience of programming and project management. He highlights the limitations of agile methods as well as their truly brilliant contributions — even those to which their own authors do not do full justice.

Three important chapters precede the core discussion of agile ideas: an overview, serving as a concentrate of the entire book; a dissection of the intellectual devices used by agile authors; and a review of classical software engineering techniques, such as requirements analysis and lifecycle models, which agile methods criticize.

The final chapters describe the precautions that a company should take during a transition to agile development and present an overall assessment of agile ideas.

This is the first book to discuss agile methods, beyond the brouhaha, in the general context of modern software engineering. It is a key resource for projects that want to combine the best of established results and agile innovations.

I haven't read the book, but I'm sure there are things about Agile that could be improved. In my limited experience I have found that one of the reasons some people do not like Agile, is the increased level of transparency, when it comes to performance. Evaluations of what everyone is doing are not done only when a project is done (months or years later), but on a continuous basis, which makes it easy for the team to make decisions as to how to deal with a team member. Sort of like keeping their feet to the fire