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

Value Stream mapping (was: Estimate vs Actual vs Velocity)

Expand Messages
  • Bill Caputo
    ... Hi Kent, Can you (or Tom if he s listening) talk a bit more about how this works? That shift in perspective from how can we do more good stuff to how
    Message 1 of 15 , Jun 26, 2006
    • 0 Attachment
      On 6/26/06, Kent Beck <kentb@...> wrote:
      > Another application is calculating the ratio of money spent actually
      > developing to money spent total. I was talking with Tom Poppendieck at XP
      > 2006 and he mentioned that in their value stream mapping exercises they
      > often find that when teams start applying agile ideas around 10% of total
      > expenditure goes to adding features. Reducing this expense ratio is one way
      > to think about improving development-- not "how can we do more good stuff"
      > but "how can we do less marginally useful stuff".

      Hi Kent,

      Can you (or Tom if he's listening) talk a bit more about how this
      works? That shift in perspective from "how can we do more good stuff"
      to "how can we do less marginally useful stuff" really rings true.

      Thanks,
      Bill
    • Kent Beck
      Bill, 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
      Message 2 of 15 , Jun 26, 2006
      • 0 Attachment
        Bill,

        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?

        Sincerely yours,

        Kent Beck
        Three Rivers Institute


        _____

        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Bill Caputo
        Sent: Monday, June 26, 2006 9:57 AM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] Value Stream mapping (was: Estimate vs Actual vs Velocity)



        On 6/26/06, Kent Beck <kentb@earthlink. <mailto:kentb%40earthlink.net> net>
        wrote:
        > Another application is calculating the ratio of money spent actually
        > developing to money spent total. I was talking with Tom Poppendieck at XP
        > 2006 and he mentioned that in their value stream mapping exercises they
        > often find that when teams start applying agile ideas around 10% of total
        > expenditure goes to adding features. Reducing this expense ratio is one
        way
        > to think about improving development-- not "how can we do more good stuff"
        > but "how can we do less marginally useful stuff".

        Hi Kent,

        Can you (or Tom if he's listening) talk a bit more about how this
        works? That shift in perspective from "how can we do more good stuff"
        to "how can we do less marginally useful stuff" really rings true.

        Thanks,
        Bill






        [Non-text portions of this message have been removed]
      • Bill Caputo
        On 6/26/06, Kent Beck wrote: (snipped example) ... I am reading this as: the higher the ratio, the less overhead? i.e. higher ratios are
        Message 3 of 15 , Jun 26, 2006
        • 0 Attachment
          On 6/26/06, Kent Beck <kentb@...> wrote:
          (snipped example)
          > 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.

          I am reading this as: the higher the ratio, the less overhead? i.e.
          higher ratios are better (all things being equal) as it means less
          non-work in the path of: id of need --> work --> use. Is that right?

          (snipped good summary of benefits and analysis)

          > Does this help?

          Very much so, thank you!

          Best,
          Bill
        • Kent Beck
          Bill, Higher ratios mean less overhead, more useful work per unit of time. A secondary effect of a higher ratio is that you get more feedback for your work.
          Message 4 of 15 , Jun 26, 2006
          • 0 Attachment
            Bill,

            Higher ratios mean less overhead, more useful work per unit of time. A
            secondary effect of a higher ratio is that you get more feedback for your
            work. If, as in JUnit, we get feedback after months for minutes of work, we
            don't have much external information with which to improve.

            Cheers,

            Kent Beck
            Three Rivers Institute


            _____

            From: extremeprogramming@yahoogroups.com
            [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Bill Caputo
            Sent: Monday, June 26, 2006 1:15 PM
            To: extremeprogramming@yahoogroups.com
            Subject: Re: [XP] Value Stream mapping (was: Estimate vs Actual vs Velocity)



            On 6/26/06, Kent Beck <kentb@earthlink. <mailto:kentb%40earthlink.net> net>
            wrote:
            (snipped example)
            > 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.

            I am reading this as: the higher the ratio, the less overhead? i.e.
            higher ratios are better (all things being equal) as it means less
            non-work in the path of: id of need --> work --> use. Is that right?

            (snipped good summary of benefits and analysis)

            > Does this help?

            Very much so, thank you!

            Best,
            Bill






            [Non-text portions of this message have been removed]
          • Ron Jeffries
            ... 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
            Message 5 of 15 , Jun 26, 2006
            • 0 Attachment
              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
              www.XProgramming.com
              Yesterday's code should be as good as we could make it yesterday.
              The fact that we know more today, and are more capable today,
              is good news about today, not bad news about yesterday.
            • Daniel Poon
              ... 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
              Message 6 of 15 , Jun 30, 2006
              • 0 Attachment
                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
              • Ron Jeffries
                ... 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
                Message 7 of 15 , Jun 30, 2006
                • 0 Attachment
                  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
                • Daniel Poon
                  ... Have we got any examples of an extreme team sending a coach to a supplier to make them more extreme? Daniel
                  Message 8 of 15 , Jun 30, 2006
                  • 0 Attachment
                    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.

                    Have we got any examples of an extreme team sending a coach to a
                    supplier to make them more extreme?

                    Daniel
                  • Kent Beck
                    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
                    Message 9 of 15 , Jun 30, 2006
                    • 0 Attachment
                      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]
                    • Jeffrey Fredrick
                      ... Agree, great example, and as a maintainer of CruiseControl makes me think a bit more about our release schedule... Can this metric also
                      Message 10 of 15 , Jun 30, 2006
                      • 0 Attachment
                        On 6/26/06, Ron Jeffries <ronjeffries@...> 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/
                      • Daniel Poon
                        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
                        Message 11 of 15 , Jun 30, 2006
                        • 0 Attachment
                          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.

                          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
                        • 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 12 of 15 , 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]
                          • 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 13 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 14 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 15 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.