Priorities, Revisited

On 2010/07/29, in agile, signal, webdev, by a b

So, I’ve been thinking more about my previous post about craftsmanship vs delivery. It seemed a little to ‘ranty’ to me, and I wanted to take another pass at what I was trying to say.

I think it’s important to stay away from an all or nothing dialog around the inclusion of quality in delivery. In general, Agile can be seen as guidelines for achieving balance. If either principle becomes a goal in itself, it limits the inclusion of other, equally important goals. The frustrating thing for developers, especially those committed to quality, is that business value should ultimately be decided by the customer! If the customer is not giving enough allowance for quality, one approach is to help them see the business value of quality, rather than simply pushing back. However, Agile provides other ways for developers to shield themselves from focus moving too far toward delivery.

A good team can work within do it’s job and still provide a balance between value, architecture, and quality, without any one thing becoming and end in itself. Minimizing complexity, or maximizing simplicity, is the principle behind stories being a seed, rather than detailed requirements. This drives us to the deferred design that comes in sprint planning. This probably the area a dev team has the most control over. I suggest developers remember to keep a balance, so that that quality doesn’t have to be completely dropped in the face of delivery pressure. Some of the ‘push back’ energy can be directed at the design process, as a reminder to keep complexity to a minimum.

In the end, the tension between customer and developers is probably a good thing. A team with out constraints may tend toward over-architecting, and a customer with no technical resistance is likely to create low quality software. For me, a big selling point of Agile is how the principles work together to make life better for both development and the customer.


Comments are closed.