Re: Re: Six Sigma and XP Estimation / Planning

--- "Eric <poetengineer-/[email protected]>" <[email protected]> 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?

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).

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. 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?

Arien


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/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/