Re: [XP] Value Stream mapping (was: Estimate vs Actual vs Velocity)

Jeffrey, You seem to apply Kent s example of a value stream for a single defect to continuous production, is that the correct way to do that? If you consider

Message 1 of 15
, Jun 30, 2006

Jeffrey,

You seem to apply Kent's example of a value stream for a single defect
to continuous production, is that the correct way to do that?

If you consider the metric as a measure of feedback for work, you can also
calculate for the work in the first month:
6 hours productive work in month 1 after 1 month:
6 hrs work time / (20 workdays/month * 8 hrs/day) = 0.0375
6 hours productive work in month 1 after 2 months:
6 hrs work time / (40 workdays/month * 8 hrs/day) = 0.1875

I am not familiar with value stream mapping so i'm not sure if this is
correct, can anyone please explain further?

> On 6/26/06, Ron Jeffries <ronjeffries@...<ronjeffries%40xprogramming.com>>
> wrote:
> > On Monday, June 26, 2006, at 11:13:03 AM, Kent Beck wrote:
> >
> > > Tom and Mary talk about value stream mapping a bit in the first Lean
> > > Software Development book, more about it in the forthcoming book
> (which I
> > > found an interesting and useful read). When I started value stream
> mapping,
> > > I just copied the lean manufacturing books and NWLean yahoogroup.
> Here, for
> > > example, is the VSM for a recent JUnit defect:
> > >
> > > 1. First noticed defect (null message being printed out as "null"
> instead of
> > > being left blank), 10 minutes
> > > 2. Waiting, 2 weeks
> > > 3. Report of defect on JUnit mailing list
> > > 4. Waiting, 1 week
> > > 5. Fixed defect, 30 minutes
> > > 6a. Committed to CVS, 5 minutes
> > > 6b1. Waiting, ??? (probably 1 month)
> > > 6b2. Release with JUnit 4.2
> > > 6b3. Waiting, ??? (probably 2 months)
> > > 6b4. Integration with IDEs
> > >
> > > So, from the time we first knew there was work to do to the time most
> people
> > > get the benefit of that work is ~4 months minimum (~3 weeks for those
> > > willing to check JUnit out of CVS). Our ratio of useful work time to
> > > non-value-adding time is 0 to several significant digits (35 minutes /
> (4
> > > months * 20 working days/month * 8 hours/day * 60 minutes/hour = 38400
> > > minutes) = 9e-4). One way to interpret the ratio is as a measure of
> feedback
> > > to work, so it says we are getting very little feedback for our work,
> which
> > > confirms my experience.
> > >
> > > The surprise for me having just done this is that the biggest
> potential
> > > improvement in the map has nothing to do with our work style,
> inefficient as
> > > it is. The biggest potential improvement by this metric is to arrange
> with
> > > the IDE vendors to roll new versions of JUnit to their customers more
> > > quickly. The second biggest potential improvement is for us to release
> more
> > > frequently.
> > >
> > > I have done this with several projects and the results have always
> been
> > > interesting, sometimes surprising. One thing I like about value stream
> > > mapping is that it points to clear areas for improvement, even if I
> don't
> > > immediately know how to improve. I haven't computed this ratio before,
> but
> > > I'm glad I can see it (and notice that I need to keep track of actual
> time
> > > to be able to compute it).
> > >
> > > Does this help?
> >
> > Delightful example, Kent! I can see how it's generally doable and
> > how it will always be interesting / surprising. Sometimes it will
> > point to things "totally" outside our control, I imagine ... but the
> > knowledge alone would cause us to think and work toward improvement.
> >
> > Nice.
> >
> > Ron Jeffries
>
> Agree, great example, and as a maintainer of CruiseControl makes me
> think a bit more about our release schedule...
>
> <thinking out loud>
>
> Can this metric also reflect the opportunity cost of more frequent
> releases, and thus suggest an "optimal" release strategy?
>
> Suppose I have 8 hours/month to work on the project and a release
> costs 2 hours -- am I better off doing 1 release/month or a release
> every 2 months?
>
> For 1 release a month there is 6 hours productive work and 1 month of
> waiting, so the value stream calculation is 6 hrs work time / (20 work
> days/month * 8 hrs/day) = 0.0375
>
> For 1 release / 2 months there is 14 hrs productive work and 2 months
> of waiting, so 14 hrs / (40 work days * 8 hrs/day) = 0.04375
>
> Clearly I must be doing something wrong because it is telling me to
> release less frequently... ;)
>
> Now if I consider the calculation for just the first unit of work, the
> 2hrs spent on the first week I get something more like:
>
> 2 hrs / (3 weeks waiting * 5 work days/week * 8 hrs/day) = 0.016..
>
> vs.
>
> 2 hrs/ (7 weeks waiting * 5 work days/week * 8 hrs/day) = 0.007..
>
> Which tells me the not surprising result that for a given bit of work
> it is better to have it released sooner... but it doesn't tell me how
> to factor in the overhead of doing a release.
>
> <preemptive>
>
> Yes, I know that eliminating the overhead of doing a release would
> make the dilemma go away. ;)
>
> Jtf
>
> --
>
> http://www.developertesting.com/
>
>
>

[Non-text portions of this message have been removed]

Pieter Klinker

Sorry, i noticed a miscalculation after posting, the idea still holds ... You can actually do 8 hours of work in the second case: 8 hours productive work in

Message 2 of 15
, Jul 1, 2006

Sorry, i noticed a miscalculation after posting, the idea still holds
though:

> If you consider the metric as a measure of feedback for work, you can
> also calculate for the work in the first month:
> 6 hours productive work in month 1 after 1 month:
> 6 hrs work time / (20 workdays/month * 8 hrs/day) = 0.0375
> 6 hours productive work in month 1 after 2 months:
> 6 hrs work time / (40 workdays/month * 8 hrs/day) = 0.1875
>

You can actually do 8 hours of work in the second case:
8 hours productive work in month 1 after 2 months:
8 hrs work time / (40 workdays/month * 8 hrs/day) = 0.025

> Kent,
>
> This has got me thinking: would Toyota differentiate between supplies
> who provide parts that end up in the end product, and suppliers who
> provide tools that are used to do the work?
>
> Certainly their approach with working on things consumed in the value
> chain is well known and widely commented on in our community. Their
> approach to working with a non-lean supplier in the value chain is I
> believe to set up a buffer between themselves and the supplier.
>
> Their approach to tooling is also documented in literature: citing cases
> where 'obsolete' equipment is used in favor of the latest most
> 'productive' models, and spending their own engineers time to modify the
> tools in order to minimize setup times.
>
> I speculate that their approach of shunning the latest equipment and
> going with the 'old model' is an analogous to putting a buffer between
> themselves and the tool vendors, who are perhaps producing features that
> Toyota don't actually want.
>
> I wonder perhaps if there is anything we can learn from this in our
> industry, but I'm not sure I should stretch this speculation any further.

I look at it a bit differently. Consider a kitchen. If you walk
into a kitchen such as I might have, you'd find a small number
of general purpose tools. If you walk into a kitchen of someone
who regularly makes gourmet meals from a many recepies,
you'll find a wide variety of tools, each specialized for a
specific purpose.

Each of these tools is much more productive for their intended
purpose, but would be the wrong tool for anything else.

Most claims of "more productive" in the industry, or any industry
for that matter, have an unwritten subtext of "more productive
when used with the process we had in mind when we designed
it."

Toyota does not use "more productive" tooling because most
of it is designed to be "more productive" when used with large
production runs of identical parts. They don't do that; and the
tool that is ideal for that purpose would work for them about
as well as combat boots on a ballerina trying to dance Swan
Lake.

Similarly, trying to convince me that I should invest
in the "latest and greatest" development tool because it has
a vastly improved debugger is futile. I haven't used a debugger
enough to be come fluent since TSO Test on MVT releases
19 and 20. The vendor may be addressing someone's need,
but they aren't addressing mine, and while they're spending
time doing it, they aren't addressing what _I'd_ like to see for
the next release.

The tool has to fit the process, or you get the tool dictating
the process. There are undoubtedly a lot of tools that would
help agile processes in general, and XP in particular. Some of
them exist, some of them are undoubtedly things we haven't
even imagined.

Take another example: code repositories. To use a technical
term, the ones we're mostly familiar with suck at effectively
storing anything other than single plain text files. Try storing
Word or OO.org files and you promptly discover that all
of their neat diff and merge capabilities are totally useless.
And that's if you don't corrupt the file by forgetting the
magic incantation that tells it that it's not a plain text file.
There are workarounds for much of it, but why? Today's
teams typically store everything in repositories; focusing on
code is so 20th century.

Or another. Many of them proudly advertise advanced
branching and merging capabilities. I don't want to get
into a long discussion of whether branching is needed at
all, but extremely capable branching and merging simply
isn't the way XP is described, nor is it the way most of
us practice it.

I could go on, but the point here is that "more productive"
is a meaningless term unless it's put into the context of
"more productive for who" and "more productive in the
context of what process model."

John Roth

> Regards
>
> Daniel
>
> Kent Beck wrote:
>> Daniel,
>>
>> I don't think (in the JUnit case) that it is my responsibility to "make"
>> Eclipse.org, JetBrains, or Sun "more extreme". If I want to deliver more
>> value with JUnit, however, I will find ways to work more closely with
>> them.
>> The JUnit team is doing this in various ways--contribution, direct
>> contact
>> with developers, mailing lists.
>>
>> This is different than the Toyota case, where they have the leverage to
>> demand continuous improvement from their suppliers. Even Toyota is
>> careful
>> to use their leverage in mutually beneficial ways, however.
>>
>> Cheers,
>>
>> Kent Beck
>> Three Rivers Institute
>>
>>
>> _____
>>
>> From: extremeprogramming@yahoogroups.com
>> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Daniel Poon
>> Sent: Friday, June 30, 2006 12:43 AM
>> To: extremeprogramming@yahoogroups.com
>> Subject: [XP] Re: Value Stream mapping (was: Estimate vs Actual vs
>> Velocity)
>>
>>
>>
>> Kent Beck wrote:
>>
>>> it is. The biggest potential improvement by this metric is to arrange
>>> with
>>> the IDE vendors to roll new versions of JUnit to their customers more
>>> quickly.
>>
>> Does this indicate that part of an extreme team's responsibility is to
>> work with it's suppliers to make them more extreme?
>>
>> Regards
>>
>> Daniel
>>
>>
>>
>>
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>> To Post a message, send it to: extremeprogramming@...
>>
>> To Unsubscribe, send a blank message to:
>> extremeprogramming-unsubscribe@...
>>
>> ad-free courtesy of objectmentor.com
>
>

Jim Standley

In Beyond the Goal Goldratt talks about incentives and penalties to encourage provider and consumer partners to keep your input buffers and inventory just

Message 4 of 15
, Jul 2, 2006

In "Beyond the Goal" Goldratt talks about incentives and penalties to
encourage provider and consumer partners to keep your input buffers and
inventory just right ... never starved and not too big. In his
manufacturing examples he can compute the dollar cost of (units * time)
of missing input or stockpiled output and take it right off partner
payments.

Ron Jeffries wrote:

>
>
> On Friday, June 30, 2006, at 12:43:24 AM, Daniel Poon wrote:
>
> >> it is. The biggest potential improvement by this metric is to
> arrange with
> >> the IDE vendors to roll new versions of JUnit to their customers more
> >> quickly.
>
> > Does this indicate that part of an extreme team's responsibility is to
> > work with it's suppliers to make them more extreme?
>
> Sure. It's a standard Lean technique. Just in time parts arrival,
> stuff like that.
>
> Ron Jeffries
> www.XProgramming.com
> Example isn't another way to teach, it is the only way to teach.
> --Albert Einstein

Your message has been successfully submitted and would be delivered to recipients shortly.