<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: What You Don&#8217;t Measure Can Hurt You</title>
	<atom:link href="http://www.galorath.com/wp/what-you-dont-measure-can-hurt-you.php/feed" rel="self" type="application/rss+xml" />
	<link>http://www.galorath.com/wp/what-you-dont-measure-can-hurt-you.php</link>
	<description>Estimation . Analysis . Planning . Control</description>
	<lastBuildDate>Thu, 09 Feb 2012 14:51:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
	<item>
		<title>By: Bruce Benson</title>
		<link>http://www.galorath.com/wp/what-you-dont-measure-can-hurt-you.php/comment-page-1#comment-207</link>
		<dc:creator>Bruce Benson</dc:creator>
		<pubDate>Wed, 27 Jan 2010 03:54:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.galorath.com/wp/?p=1223#comment-207</guid>
		<description>I&#039;m not sure we would want to measure the people directly in any sense.  I think that would be the equivalent to measuring manufacturing process when saying &quot;people are the software development process.&quot;  That would make little sense and I doubt anyone ever considered that approach. 

In a real world example, we had a small QA team assigned to &quot;double check&quot; our defect prioritization process.  They were to see if we were &quot;accurately&quot; identifying the priority assigned to each defect.  No methodology was used, just the joint opinion of the assigned team (I guess is was a wisdom of crowds/delphi technique).

They would send me a list of defects each day that they considered mis-prioritized. Every day, we got a list of defects we needed to adjust the priorities on, and we did.

I did an analysis to compare their &quot;new priorities&quot; and the final disposition of those defects to those defects that were not adjusted.  

In a nutshell, what they were doing was indistinguishable from randomly selecting defects and just assigning a higher priority (as opposed to finding truly under-prioritized defects). 

One of the members of the group admitted that they felt they must always find something in the hours they spent each day in this review, otherwise they would not be seen as doing their job.  I jokingly suggested we replace the team with a random selection process, but nobody seemed amused (saving ~10 people salary x ~2 hours a day ...).

We could tell the added QA process was ineffective because we were measuring the defect repair process and understood how it performed.  Many folks don&#039;t get it that this is possible in many cases and works very well (and we were not measuring people per se, but the overall repair process). 

Thanks for provoking the memory.  

Bruce Benson
http://PMToolsThatWork.com</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure we would want to measure the people directly in any sense.  I think that would be the equivalent to measuring manufacturing process when saying &#8220;people are the software development process.&#8221;  That would make little sense and I doubt anyone ever considered that approach. </p>
<p>In a real world example, we had a small QA team assigned to &#8220;double check&#8221; our defect prioritization process.  They were to see if we were &#8220;accurately&#8221; identifying the priority assigned to each defect.  No methodology was used, just the joint opinion of the assigned team (I guess is was a wisdom of crowds/delphi technique).</p>
<p>They would send me a list of defects each day that they considered mis-prioritized. Every day, we got a list of defects we needed to adjust the priorities on, and we did.</p>
<p>I did an analysis to compare their &#8220;new priorities&#8221; and the final disposition of those defects to those defects that were not adjusted.  </p>
<p>In a nutshell, what they were doing was indistinguishable from randomly selecting defects and just assigning a higher priority (as opposed to finding truly under-prioritized defects). </p>
<p>One of the members of the group admitted that they felt they must always find something in the hours they spent each day in this review, otherwise they would not be seen as doing their job.  I jokingly suggested we replace the team with a random selection process, but nobody seemed amused (saving ~10 people salary x ~2 hours a day &#8230;).</p>
<p>We could tell the added QA process was ineffective because we were measuring the defect repair process and understood how it performed.  Many folks don&#8217;t get it that this is possible in many cases and works very well (and we were not measuring people per se, but the overall repair process). </p>
<p>Thanks for provoking the memory.  </p>
<p>Bruce Benson<br />
<a href="http://PMToolsThatWork.com" rel="nofollow">http://PMToolsThatWork.com</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

