Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Pieter Klinker
    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 11:40 PM
    • 0 Attachment
      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?

      Sincerely,

      Pieter

      On 01/07/06, Jeffrey Fredrick <jeffrey.fredrick@...> wrote:

      > 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
      • 0 Attachment
        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

        Pieter


        [Non-text portions of this message have been removed]
      • yahoogroups@jhrothjr.com
        From: Daniel Poon To: extremeprogramming@yahoogroups.com
        Message 3 of 15 , Jul 1, 2006
        • 0 Attachment
          From: "Daniel Poon" <mr.d.poon.at.gmail.com@...>
          To: "extremeprogramming@yahoogroups.com"
          <extremeprogramming.at.yahoogroups.com@...>
          Sent: Friday, June 30, 2006 10:31 PM
          Subject: [XP] Re: Value Stream mapping (was: Estimate vs Actual vs Velocity)


          > 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
          • 0 Attachment
            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.