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

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

Expand Messages
  • Pieter Klinker
    Jun 30, 2006
    • 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]
    • Show all 15 messages in this topic