Thank you for the comment. I really like your post and I agree. Isn’t it odd how we put quality decisions in the hands of our customers? Since they are ultimately paying for the work they should have a say in some of the tradeoffs we face but, at the same time, they need to understand the impact of these decisions.

I don’t think home builders tell their clients that if they remove some of the support beams in a house they can finish construction sooner and lower the cost. I don’t want to have that kind of conversation with my clients. But in agile we want our clients to constantly check in with us and adjust their priorities. This is natural and is part of the discovery process of developing software.

I encourage my clients to change their priorities of what they want built but not how we build it. I always build with quality but only address the requirements at hand. This does not mean I’m a perfectionist when building software.

To me quality is like building codes for a home builder. I follow certain practices to ensure that what I’m building is robust. I reject the notion that quality takes longer or is unnecessary. The kind of quality standards I follow actually speed things up and definitely helps build software that does what it is supposed to. This is what I show developers and teams how to do in the training, coaching and consulting I offer.

David.

Excellent post! This conflict seems to arise frequently in almost all software development organizations. I wrote a post along similar lines back in January http://ow.ly/25xAy

You may want to use the values exercise I outline in the post as a way to help communicate the cost of “Just getting it out the door”.

Let me know if you have any luck!