A well written article, but this is exactly the type of thinking that has brought Development in America to an all time low and why ultimately businesses continue to seek external resources.

Agile Development is definately a methodology that allows the customer to see more frequent results. From a Business perspective, that may be what your customer wants to see. However, what they want and what they need are often two very different things and this is absolutely an area where a customer's ferver for a 'visual fix' each couple weeks should be managed. The very best project managers try to balance the customer's excitement to see something against the need for quality and attention to detail. For those projects with no real competent technical project management and no layer inbetween the develper and the customer, Agile may be the only way to passify the customers regular need for that 'fix'. However, you are ultimate not serving that customer or yourself and you are exchanging true development quality for short term customer satisfaction during the development process.

For me personally, I believe the Sales and Marketing parts of our industry have encouraged this approach because it makes more sense to them and unfortunately, we'll always have a set of 'experienced' people who buy into the hype and the cool word "Agile".

While I'm certainly no advocate of a long drawn out waterfall model where you do 6 months worth of hardcore development before anyone see's you emerge from a cube, I KNOW a far better result will be achieved for a project that is managed by clear and early identification of MILESTONES at regular short intervals. Those milestones don't necessarily need to be some new screen that a customer can see, but are still identifiable progression points that at the very least, a develper and technical project manager can identify and agree on and measure.

I'll completely agree that great team communications and regular measurement points are fundamental to a project and those aspects of Agile are points well considered for any developer. However, the precepts of Agile involving the complete end-to-end development of one small piece of the project at a time often defeats the goal of having a well thought out system archtecture with the necessary attention to system integration that great products display. You can say that you can overcome this by having a lot of communication, but in practice it doesn't work that way.

For a set of software development tasks that have been repeated by develpers a few hundred times in their career, Agile makes a lot of sense. For the other 98% of the projects that most of us find ourselves doing, the process will ultimately work against a quality result.

Brad Benham

Senior Architect

McKesson Corporation