|
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 tradeoff?
- What distinguishes a conscious from an unconscious tradeoff?
- What is the impact of trading off quality for speed?
- What can you do to change the choice?
A tradeoff 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 tradeoffs. And I want the choices about tradeoffs
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. In QSM Vol. 4, Jerry Weinberg 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 decrease both of them.
What are we getting? Faster deliver 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 tradeoffs are unconscious, provide the
team with your interpretation of what the team is getting, giving up, and why. And
compare it to a tradeoff that you consider will provide more value. You may be surprised
how making things explicit offers an opportunity for management to choose differently.
©2007 Steven M Smith
Reference
Jerry (Gerald M.) Weinberg, Quality Software Management: Volume 4, Anticipating
Change, ISBN 0-932633-32-3, pp. 175-192.
Trackback(0)
 |
Tags
TrackBack URI for this entry
Subscribe to this comment's feed
Show/Hide comments
Show/Hide comment form