Ken,
Your Honeywell story is a good one. I have soooooo many like it. Back in
the days of
heavy-duty causal analysis at one nameless company, we were always amazed
at what
management had decided to "count" :-)! When there is no trust and no communication,
the replacement is usually this kind of attempt to control the environment
that results in
exactly the kind of craziness you describe.
Linda
Ken Schwaber wrote:
href="" class="moz-txt-link-freetext" href="http://jeffsutherland.org/">http://jeffsutherland.org/>
Jeff Sutherland found a stealth article by Mike Cohn. It has some really
solid thinking about defect metrics. I've been thinking more about this
lately as part of the "potentially shippable increment" that is demonstrated
at the end of each Sprint. Because the product owner wants to know what
is being demonstrated, knowing the solidity and bugginess of the increment
is important. Is the product owner seeing something that really is potentially
shippable, or does it need two Sprints of testing and debugging first?
As Mike points out, though, measuring defects is tricky. Whenever you measure/observe
something, it changes. I remember a problem at Honeywell with their process
control computers. The customer engineers were taking too long at customer
sites to fix them, and the over CE cost was increasing. So, bonuses were
instituted for CE's that reduced "onsite" time fixing the computers. The
result? The onsite time went down as the CE's stopped fixing the computers
and started doing component swapping, taking out potentially fixable components
and replacing them with really expensive new components. Watch out what
you ask for, because you might get it.
Ken
![]()
Cohn, Mike. (2002) "A Measured Reponse: Useful metrics to give managers
the numbers to back up project hunches."
STQE 4(5):20-25, Sep-Oct.
A few years ago, I was leading a large development group and the leaders
of the Quality Assurance team visited me. They said they were ready to provide
me any metrics I wanted. AlI I wanted was bugs found vs. bugs fixed day
by day for each product along with cumulative bugs outstanding by day. Looking
crestfallen, they asked if that was all.
That is all I wanted, a simple metric, that turned out to take a lot of
work for them to provide it for dozens of products under development. It
tells you how much QA work is getting done, how buggy the product is, whether
the bugs are overwhelming the ! development team as you approach ship date,
and so forth. You can largely predict the success of the rollout of a new
product by knowing this single metric.
There does not seem to be a lot written about this simple metric. I was
happy to see Mike Cohn make it the centerpiece of his article. Recommended.
--
Posted by Jeff Sutherland to
Jeff Sutherland's Object Technology Web Site
at 12/13/2002 6:12:32 PM
Powered by
Blogger Pro
To Post a message, send it to: object-technology@xxxxxxxxxxx
To Unsubscribe, send a blank message to: object-technology-unsubscribe@xxxxxxxxxxx
Your use of Yahoo! Groups is subject to the
Yahoo! Terms of Service
.
To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx
Your use of Yahoo! Groups is subject to the
Yahoo! Terms of Service
.
