Re: Re: SIP is not Takt Time

On Monday, February 10, 2003, at 4:47:12 AM, Dan Palanza wrote:

>>(I don't think we need new terms for most of this stuff, let's just
>>use an existing set where we can.)

> Good thinking, but might it be wise to model software's production 
> terminology in analogy to a product whose production plan more resembles 
> software's. A high volume assembly line, lean or otherwise, seems to me to 
> have little resemblance to producing software.

> Creating a movie, or a play, would seem to form a truer analogy. A design 
> plan and budget essential to building small buildings makes that trade a 
> lot closer than high production items as well. Using analogy as a source of 
> terminology is a good idea, but picking a likely analogy seems just as 
> important.

Recognizing that analogies fail us here is important. There are aspects of
software development that are much like creating a movie (at least to a guy
who has never created a movie). Each feature is like a scene. It has some
planned place in the movie, but it can be filmed at any time. In the final
edit the scenes might be reordered or even cut. We might even go back and
film some scenes after the main filming is done, to change or add something
important.

It seems to me that this long involved discussion of takt and lead and
cycle time is far from the original notion that Kent raised:

  Here is the metric -— the average number of days between when a new
  feature of a system is specified in detail and when it is first in the
  hands of real users, making you real money (or at least letting you know
  exactly why aren’t yet going to make real money.) I call this gap between
  specification and deployment Software-In-Process, or SIP. If a marketing
  person says a new feature should work like thus and so, and yadda yadda
  yadda four months later a real user really uses the feature, that part of
  the project gets a SIP ~ 120.

On a pure XP project, if I understand XP and understand SIP, SIP is the
(average) time from the first day of the iteration that implements a story
until the day the entire system is next released to end users. I shall
explain. No, it is too much. I shall sum up:

  SIP is "number of days between when a feature is specified in detail and
  when it is first in the hands of real users".

  A feature is clearly in the hands of real users when the system is next
  released, and not before.

  A feature is fully specified in XP by the conversation that takes place
  when it is actually built, and by the customer tests which are provided
  in the iteration that builds it.

On a more conventional project, SIP is the (average) time from the day you
have written a feature's full requirements document until the day the
entire system is next released to end users.

Kent's point, and he did have one, was that by reducing the time spent in
useless documentation, thus increasing the frequency of shipping, you
reduced SIP and gained value more quickly:

  The less work-in-process inventory we carry, the more feedback we get. If
  there is a six month gap between making a specification decision and
  realizing that the decision places an uneconomical burden on the system’s
  design, there is no chance of catching the mistake early. If we can
  reduce the gap between decision and consequences, however, we have a
  chance of fixing the mistake when the consequences are small, and of
  learning not to make the same mistake in the future.

  Fixing mistakes when they are small and learning to work better in the
  future are both ways of saying the more feedback we get, the less effort
  we waste. Less waste leads to more predictability (and also, I’ll claim,
  greater return on investment.) Here is where the picture changes. Imagine
  that you are on a project that just went from yearly releases to
  semi-annual releases by eliminating a bunch of useless paperwork.

  Sure, the doomsayers were out in force, claiming that you were abandoning
  the tried and true methods that had worked “so well” in the past.
  However, you shipped something in 180 days. It wasn’t easy, but it wasn’t
  bad. You know what you could do better next time.

  Fast forward a year. Semi-annual releases are now standard practice, and
  everyone is claiming to have initiated the idea. If 180 days was better
  than 360, what would happen if you went to 90? The more in control you
  feel, the more confidence you have that you could work with even less
  work-in-process inventory.

  Bingo! Positive feedback loop. The less work-in-process inventory you
  carry, the less work-in-process inventory you have to carry.
  Predictability comes along for the ride.

Software isn't or chocolate cherries. In chocolate cherries, it probably
matters how long it takes to make one, and how often we have to stop the
line because someone discovers a cherry pit in the cherry feeder. The
issues of cycle time, lead time, takt time make sense.

Do they make sense in software development? I'm not sure. I'm here to
report that, to me, the discussion is getting further and further from
Software In Process, and I wish it would come back. I don't like chocolate
cherries.

Ron Jeffries
www.XProgramming.com
FEAR = Fantasy Experienced As Reality
------------------------ 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/