Re: Re: SIP is not Takt Time

On 2003.02.08, Mary Poppendieck <[email protected]> <[email protected]> wrote:
> I agree, takt time is the goal, not the actual time.  Say you want 
> 100 cars to roll off your line in an 10 hour day, that means that 
> they need to roll off at the rate of 10 per hour or one every six 
> minutes.  So six minutes is the desired takt time.  I reluctantly 
> concede that the actual rate at which cars are rolling off the line 
> (say one every 7 minutes) can be called cycle time.  By whatever 
> name, this time is not a duration, it is a rate.

Cool, so we're in sync. here.

> What I think about, however, is not how many stories per week (or 
> whatever) a team can complete, I worry about how long it takes a 
> story, once articulated, takes to get finished.

I think this illustrates the lead time vs. cycle time confusion again.
Your worry is from a programmer-centric view -- what is important from
their perspective is "once work is assigned, how long does it take for
me to complete it" (i.e., what is the cycle time of my task/step).

From a business perspective, they're looking for the cycle time of the
entire story, which they might call "lead time" to having the feature
implemented/deployed -- which will include the cycle time for the
programming team's work, as well as the cycle time for the business
Customer to specify the story itself, as well as any auxillary testing
or documentation cycles that must be carried out if necessary.  The
entire process would be the lead time for the feature ... and I think
SIP should be the measure of that lead time.

From personal experience, I've worked on some stories that took
(literally) 6 hours to implement but almost 10 business days to write
the story itself.  Our team's velocity is pretty high ... but there are
some iterations when we have to postpone the Planning Game three,
sometimes four days, because the Customer is still getting the necessary
agreements from the rest of the business before the story can be handed
over.  IMHO, this delay (or, cycle time of the Customer's story writing)
is important to track ... perhaps seperately.

> This time – whatever we call it – is the important time for SIP.

See what I wrote above and see if you still feel that the
time-to-complete-a-story is still the important time for SIP.

I'd say that each cycle (story writing, programming, testing,
documentation, etc.) should be measured individually, and the sum of all
cycles should be considered SIP.  Even if one cycle is short, if another
cycle gets larger, SIP will increase.

I look at it like this:  your customer only cares about finished goods
inventory.  If you have a shortage in your raw materials inventory, the
customer doesn't care that your cycle time for turning raw materials
into inventory is "only 6 minutes long" ... if you have to wait 4 weeks
for enough raw materials to make 1,000 widgets, then your effective
cycle time (from the customer's perspective) is 15.6 minutes -- over
twice as long.  Basically, the customer only cares about their lead time
getting your finished goods into their hands.  I think this is the
important time that SIP should measure.

> I used to call this cycle time, now I call it service time, some
> people call it lead time.  Basically it is the time from when
> something goes into a queue until the time it comes out.  It is a
> duration, not a rate. I don't think we have a word for the target of
> this time – but I surely could be wrong. 

It's definitely a duration and citations of the measure should include
sufficient context to make sense of it.  What you want to call "service
time" I've always known as "calendar time" -- the actual amount of time
on the calendar that passes before an event.  By its very name it
signals that it's a duration.

The nice thing about rates are that they're context-free -- N units per
T time just is.

Durations are tougher to work with because of the requisite context.
Saying "it takes us two weeks to turn around raw materials into one
finished good" implies a lot of unspoken dependencies, any one of which
could affect the duration.  So, to simplify, we speak in terms of
calendar time: it's Feb-8 today and we'll have one unit done by Feb-22
(two weeks).  This makes some promises against those dependencies but
nails down the duration to a specific point in time (context) -- this
doesn't guarantee that starting Feb-22 we'll necessarily be able to
produce another unit by Mar-8 -- we didn't say anything about those
dates and we didn't make a generalized claim that "we do 1 unit per 2
weeks" which would be a rate, not a duration ...

This is why in my XP projects, when I provide estimates, I give the
following "numbers":  estimate in ideal days, estimated start date,
estimated delivery date.  Based on the team's velocity, any staffing
fluctuations (vacation, off-site training, etc.) we can compute when we
think the story will be started and when during the iteration we think
it'll be delivered.  This helps the Customer steer because it lets them
schedule their time (since they provide Acceptance Testing and
Documentation) ... and after I introduced the start/delivery dates, they
stopped asking why "this one-point story took longer than that two-point
story to deliver?"  Trying to explain that the durations vary from week
to week was much easier done through an illustration using real dates
than trying to explain fluctuations in cycle time ...

Thanks for the exchange, Mary.

-- Dossy

-- 
Dossy Shiobara                       mail: [email protected] 
Panoptic Computer Network             web: http://www.panoptic.com/ 
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

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