Re: Six Sigma and XP Estimation / Planning

Some responses in brackets {{ after asterisks *** in the 
interchange below.


--- In [email protected], Arien Malec 
<[email protected]> wrote:
> 
--- "Eric <[email protected]>" <poetengineer@y...> wrote:
 The Define and Measure step are focused on understanding the 
 business environment and capturing the customer 
 requirements.  Six Sigma is very focused on understanding and 
meeting or exceeding customer requirements. From that 
 perspective, the extremecustomering / XP approach of including 
 a representative of the customer in the development process is 
 fantastic!
> 
> From that standpoint, I'd ask in general, how would one 
approach software
> development from a 6S perspective? As far as I understand, 
the first step would
> be to establish the quality characteristics that are important to 
the customer,
> and focus the DMAIC process on those characteristics?

***  {{ Yes, you are right - from a six sigma perspective, one of the 
first steps would be to establish the quality characteristics that 
are important to the customer.

The DMAIC process is for process improvement; a similar 
process, called DMADV is used for new products and such - in 
this case, new software development.

DMADV stands for Define / Measure / Analyze / Design / Verify.

The Define step would involve understanding the business 
environment and requirements, and the influence they pose to 
the project.

The Measure step would be the step you mention - establishing 
the characteristics that are important to the customer. Many of 
these are quality characteristics, but the step also involved 
capturing other customer expectations that you might not 
consider quality characteristics.   

The approach that XP  uses - including the customer as part of 
the team that captures customer requirements and expectations 
- is entirely consistent with the Six Sigma approach, although it is 
not always possible to include the customer so intimately - so 
alternative approaches  are often used }} ***


> One subsidiary debate here is how XP manages 
requirements. The traditional
> software development process attempts to achieve 
conformance to requirements.
> XP does this as well, but is also concerned with fitness for 
use, and so
> explicitly allows the requirements to be tested against 
business needs.
> 
> (This is done in three principal ways: 1) Encouraging 
discussion between the
> developers and customers about the "user stories" which is 
how XP captures
> requirements, 2) Asking the customer to establish testable 
requirements against
> the stories: these are called "customer tests" in XP, 3) 
Showing the customer,
> every 2 weeks or so, the software produced to date, to ensure 
that it
> represents the customer needs.)
> 
> One concern some of us had about 6S (on the basis, of 
course, of speculation
> and little evidence) would be that it would take a conformance 
to requirement
> perspective, rather than a fitness for use perspective. I wonder 
if you could
> address that? (I would suppose that a manufacturing line 
analogy would be to
> focus on how closely we produce widgets within tolerance, but 
ignore whether we
> are producing the right widgets at the right times).

***{{ If I understand correctly what you refer to as "fitness for use", 
then Six Sigma does take that perspective in the DMADV 
approach for new product development.

The conformance to requirements perspective is a Quality 
Control or Quality Management System perspective.  Six Sigma's 
DMAIC process is considered a business improvement method 
that focuses on improving business results -so producing the 
right widgets at the right times is very much a part of applying Six 
Sigma to a manufacturing line, as you mention. 

Similarly, it is not good business practice to treat software as if it 
were a simple mechanical product in which meeting 
specifications is the end-all.  It is not good business practice to 
develop software that conforms to requirements but won't sell or 
won't satisfy the customer because it isn't fit to use or is so 
user-unfriendly that only the software developers can use it. }}***




> For the planning issue:
> 
> > In the situation under discussion, it appears that the 
customer 
> > requirement that you are addressing is the development 
time:
> 
> Actually, XP holds iteration time fixed. The issue under 
discussion is how much
> work can be done in that fixed amount of time, which is why the 
term "velocity"
> is used. XP attempts to break work down into small, mostly 
uniform chunks,
> called "story points". Velocity is defined as the number of 
points that can be
> completed in an iteration. (V = P/I)
> 
> [modeling velocity]
> > One statistical modeling approach would be to assume 
> > independence for each of these iterations. You've indicated, 
and 
> > I would also suppose, that these iterations are not 
independent - 
> > they are in fact autocorrelated (correlated with themselves: if 
you 
> > know the velocity of iteration X-1, you might have some 
indication 
> > of  what the velocity of iteration X might be). This 
autocorrelation 
> > is part of what you want to understand. 
> 
> The XP assumption is autocorrelation. Actually, the XP 
assumption runs
> something like this:
> 
> 1) Very strong autocorrelation (V(n+1) = V(n)) is good 
assuption for predicting
> the velocity of future iterations
> 2) An assumption of very strong autocorrelation provides a very 
cheap mechanism
> for prediction
> 3) Any other mechanism for prediction is likely to destroy more 
value (by
> taking time and resources) than it is to create value (by 
increasing
> predictability)
> 
> 
> Also, velocity is likely to be more unpredictable at the beginning 
of a
> project, but is likely to settle down in the middle and towards 
the end of a
> project. The very strong autocorrelation assumption is thus 
likely to be
> self-correcting, whereas using past performance is likely to 
skew our results.
> 
> > To be honest, I'm not at all clear about the nature of the 
> > autocorrelation - if I speak in terms of time rather than 
velocity, 
> > then I can argue that the autocorrelation between the time for 
> > iteration X-1 and iteration X would be positively correlated:if it 
> > takes a long time to perform iteration X-1, it will probably take 
a 
> > long time to perform iteration X.
> 
> That's the assumption.
>  
> > However, I can also argue a negative correlation in terms of 
time: 
> > if I spend a lot of  time on iteration X-1, doing a very thorough 
job, 
> > then it might take less time to perform iteration X.
> 
> Again, since story points are uniform work units, and iterations 
are fixed time
> periods, this is not likely to happen. Indeed, the development 
team looks at
> story point estimates in the iteration planning meeting: if 
something has
> happened to make a story cheaper than previously assumed, 
the team would mark
> down that story, and take on more work for that iteration, 
keeping within
> established velocity.
> 
> > So, just to start out, let's make an initial assumption that the 
> > iteration times are uncorrelated.  
> 
> This is a poor assumption, IMHO. 

*** {{ Yes, it is a poor assumption, but it is an initial assumption 
that can be built on. 

For example -  high  positive autocorrelation, as you are 
assuming, would approximately double the variance that would 
be expected from the assumption that iteration rates are 
uncorrelated.   *** }}


For instance, any of the below could and do
> happen:
> 
> 1) The team may have "jelled" since the beginning of the 
project, and now work
> together better
> 2) The team may understand key aspects of the project 
(technical, business)
> better now, than before
> 3) Resources may have changed (larger, smaller) with 
non-linear and
> difficult-to-predict effects on velocity (we may see velocity go up 
when people
> are removed and see velocity go down when people are 
added).
> 
> [Gamma distribution for velocity]
> The assumptions you use to choose a Gamma distribution 
sound correct. 
> > Now, there is a way to take this approach, which assumed 
> > independence, and adapt it to a situation where there are 
> > correlations.  If appropriate, I'll go into that later.
> > 
> > There are also numerical simulation approaches, using 
discrete 
> > event simulation tools to simulate running through the same 
> > sequence of  iterations thousands of times, and then seeing 
a 
> > histogram that would be an estimate of the gamma 
distribution 
> > of the total development time from that sequence of 
iterations.
> > This is a variation of a statistical approach called Monte 
Carlo 
> > simulation.
> 
> The question we would want to ask here is: Does using these 
techniques produce
> more value to customers (increased predictability) than it 
destroys through the
> increased effort of using it, and the increased complexity of 
understanding the
> results?

*** {{ You ask another excellent question here. 

When you use these techniques, you are building a stochastic 
model ( a fancy name for a "statistical model") of your software 
development process.

A famous statistician named George Box said, "All models are 
wrong. Some models are useful".

Basically, the model you create for your software development 
process will be wrong, in that it will not precisely predict future 
results.  However, it can be useful - just as models of electronics 
are useful in designing and developing new electronics products 
and models of manufacturing processes can be useful in 
improving the manufacturing line.

The key, I think, is to be sensitive to the point where you run into 
diminishing returns.  You can build a fairly simple statistical 
model for the software development process with very little 
investment of time or resources. If it looks useful, you can put in 
a little more time to improve the model. If it looks like it can help 
you improve things that are important to you and/or your 
customer and/or your management chain (such as giving better 
estimates of the time required to develop new software), then 
this is a case where the "model is useful". 

You can keep putting in time and effort improving the model, but 
at some point you will find that you will be putting in an awful lot 
more time for almost no benefit in terms of improved accuracy 
with a model that George Box indicated will always be wrong.
You will have reached a point of diminishing returns, and you 
should consider simply using the model as is for the benefit that 
it provides. }} ***
 - Eric Maass



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/