The people whose opinion counts the most choose to go for faster delivery speed. Their thinking may be sound; in this case, they want to beat their competitors to market.
Choosing faster product delivery visibly sacrifices product quality and, in my experience, it often invisibly sacrifices the economy of product support. In this post, I answer the following questions:
- What is a trade-off?
- What distinguishes a conscious from an unconscious trade-off?
- What is the impact of trading off quality for speed?
- What can you do to change the choice?
A trade-off is an engineering tactic for generating as much value as possible for your customer and your organization when circumstances don’t allow you to satisfy every desire. I have yet to experience a development project where everyone’s desires could be satisfied so I expect trade-offs. And I want the choices about trade-offs to be conscious rather than unconscious.
It’s a conscious choice when I know:
- What are we getting?
- What are we giving up?
- Why?
It’s an unconscious choice when I or any member of the development team can’t find answers to the above questions. And when the answers can’t be found, the team is wishing rather than planning for success.
Let’s return to the choice of going for delivery speed. Jerry (Gerald M.) Weinberg in his book Quality Software Management Vol. 4: Anticipating Change insightfully points out the triangular relationship between the variables—product quality, delivery speed, and development economy. In development projects, Weinberg says these variables are locked in a stabilizing feedback loop. A choice to increase any one of the variables will decrease one or both of the other variables.
For instance, if we choose to increase the delivery speed, we decrease product quality or decrease development economy or we decrease both quality and economy. In other words, the choice for faster delivery may result in an inferior product as well as costlier development.
What are we getting? Faster delivery speed.
What are we giving up? Perhaps desired functionality. Perhaps a defect free product. Perhaps employee morale. Perhaps delighting the customer.
Why? Perhaps beating our competitors to market. Perhaps satisfying a big customer who will buy other products if we deliver early. Perhaps winning an industry award.
I don’t like all of these answers, but I like that they are explicit. Regardless of whether I like them, they are all legitimate.
When development organizations go for speed, my experience is management rarely focuses on the additional support cost triggered by shipping a product faster. In these companies, development and support were in separate organizations. They each had their own budgets. Development had financial incentives to go fast and that choice had a big impact on support. What can be done about this problem? Create a strong feedback loop back to development. I suggest charging development for support. They won’t like it, but the less the number of faults, the less they pay, which puts part of the economic impact of their development choices back on them.
What can you do to change choices? If the trade-offs are unconscious, provide the team with your interpretation of what the team is getting, giving up, and why. And compare it to a trade-off that you consider will provide more value. You may be surprised how making things explicit offers an opportunity for management to choose differently.
Please also see my related post Trade-off: Go For Quality.
Leave a Reply