Re: Re: Six Sigma and XP Estimation / Planning

Hi Eric,

[snip]

> In the situation under discussion, it appears that the customer
> requirement that you are addressing is the development time:

Terminology is probably the biggest problem in talking with other
disciplines.  I got the feeling from reading the rest of your post that you
may have misunderstood the term "velocity."  Of course, it may just be that
I misunderstood what you wrote ;-)  I thought I'd reply with a couple of
definitions and a little high-level explanation to see if we could find out
which it is.  I'm going to generalize here, accepting the risk that there is
variation in practice.

"Velocity" in XP's terminology is a measure of work.  It's counted in
"stories" which could also be talked about as features.  Customers tell
"stories" about how the software will be used.  So a project's velocity is
basically a measure of output.

XP uses time-boxed approach to development where a project is divided into
fixed-duration "iterations."  The duration any particular project will use
is up to the project team, but iterations durations are typically set at 1-3
weeks.  Once a team settles on an interation size, say for example 2 weeks,
all iterations for that project will be 2 weeks.  There's no variation in
iteration duration for a specific project.

Probably the most important difference between XP and more traditional
approaches to software development is that XP takes the position that, given
X amount of time to produce a result, the appropriate thing to manage is
scope (i.e., the *amount* of functionality in the application).  In the more
traditional approaches, scope is more or less fixed in the beginning of the
project and what gets managed in the end is quality.  So software gets
shipped with lots of defects still in it.

Using XP's approach, the software that comes out of each iteration is very
high quality.  The question that get's begged, however, is this.  Given a
fixed release date, say 3 months / 6 iterations from now, how best to
predict what will have been produced?  And how best to predict, at the
beginning of each iteration, what should be committed to for that iteration.

I should stop now and see whether any of this helps, or whether I'm the one
in need ;-)

Best regards,
Bill

> =====================
> "In particular, I'm wondering about the practice of committing to a
> velocity for iteration X that's equal to the velocity achieved in
> iteration X-1.  As I said earlier, I have a feeling that could be
> perceived as "shooting low."  I wonder if 6S's statistical
> underpinnings might recommend a different approach that
> wouldn't put any more pressure on the development team re:
> unrealistic committments but, at the same time, answer this
> question plus the question about whether / how many stories
> should be estimated and in the queue in case the team
> accomplishes more than initially committed in an iteration."
> ======================
> >From a Six Sigma perspective, the issue is one of
> understanding and modeling the uncertainty - which we equate
> to variability, or the statistical term, variance.
>
> In other words, if you knew with certainty the time it would take for
> iteration X, given the known velocity achieved in iteration X-1, then
> there would be no problem with projecting the development time.
>
> So, we would approach this as the need to develop a statistical
> model (also called a "stochastic model") for the development
> time.
>
> There are several ways to develop such a model, but let me start
> with a fairly simple model that derives from the description you
> give.
>
> Let's imagine the sequence of steps is the iterative process you
> describe:
>
> Iteration 1 ---> Iteration 2 --....-->Iteration X-1 ---> Iteration X
> --->Iteration X+1.....--> End
>
> Now, each iteration occurs at some velocity and consumes
> some amount of time.
>
> 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.
>
> 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.
>
> 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.
>
> So, just to start out, let's make an initial assumption that the
> iteration times are uncorrelated.
>
> With this assumption,we would estimate the distributions of
> times for each iteration, then use those distributions to project
> the distribution of the total development time.
>
> Now, each of these iteration times would not be expected to
> follow normal distributions. There is a minimum time that you
> would need to spend on each iteration - the minimum time could
> be zero (by contrast, a normal distribution would allow for the
> possibility of negative development times).  There would be an
> expected time for each iteration, but there would be no maximum
> time - each iteration could theoretically take forever, although that
> might make someone a little bit unhappy.  However, there would
> be an estimate of the standard deviation - the uncertainty - of the
> distribution of time for the iteration; the square of that standard
> deviation would be the variance.
>
> This type of distribution is called a Gamma Distribution. You
> would obtain an estimate of the gamma distribution of time for
> each iteration, then obtain a new gamma distribution for the
> project - it would have a minimum time, equal to the sum of the
> minimum times for each iteration, a most likely  time, equal to
> the sum of the most likely times for each iteration, and a
> variance...equal to the sums of the variances for each iteration.
>
> 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.
>
> This message is getting long, so I'll try to continue it in a later
> message.
>
> Best regards,
> Eric Maass
> Chairman, Six Sigma Steering Committee, Motorola SPS
>
> --- In [email protected], "Bill Walton"
> <[email protected]> wrote:
> > We're joined now by a real Six Sigma guru.  His name is Eric
> Maass.  Eric is Director of Technology Strategy for Motorola's
> Wireless and Broadband Systems Group.  At the same time, he
> is Chairman of the Six Sigma Black Belts Steering Committee for
> Motorola's Semiconductor Products Sector.   He has a web page
> at http://www.geocities.com/ecmaass/ for anyone who wants to
> check out his CV.  In a conversation with another 6S guru who
> hasn't had time to join us I was told "I think you hit the nail on the
> head. The future is really in a balanced mix of XP and Six Sigma."
> So I have some high hopes that, in talking with Eric, we may find
> that XP has an ally in 6S that could bridge some communication
> gaps with organizations that are doing 6S, or at least think highly
> of it, but who don't know as much about XP.
> >
> > I posed a question earlier about whether / to what extent XP
> would find support for it's estimating / planning practices in a Six
> Sigma environment.  In particular, I'm wondering about the
> practice of committing to a velocity for iteration X that's equal to
> the velocity achieved in iteration X-1.  As I said earlier, I have a
> feeling that could be perceived as "shooting low."  I wonder if
> 6S's statistical underpinnings might recommend a different
> approach that wouldn't put any more pressure on the
> development team re: unrealistic committments but, at the same
> time, answer this question plus the question about whether /
> how many stories should be estimated and in the queue in case
> the team accomplishes more than initially committed in an
> iteration.  I also tend to think XP's practice of picking a "best
> guess" at an initial velocity and then adjusting based on actual
> results (as opposed to trying to develop a long term timeline that
> will be difficult to adjust, etc.) may find support in 6S in the
> context of establishing a baseline.
> >
> > Eric is new to XP and has expressed a need to come up to
> speed on the practices and the terminology.  I thought it would
> be best, since practices are evolving, since there seems to be
> some variation in practice, and since I'm still researching XP as
> opposed to actually doing it, to ask you guys to explain the
> estimating / planning practices you use.  Or, if you like, I could
> explain it as I understand it from my readings and talking to you
> here and let you correct me as necessary.
> >
> > Best regards,
> > Bill
>
>
>
>
> 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/
>
>
>



------------------------ 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/