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

RE: [scrumdevelopment] WIP

Expand Messages
  • Clarke Ching
    lovely analogy Mary! _____ From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck Sent: 02 September
    Message 1 of 27 , Sep 2, 2005
    • 0 Attachment
      lovely analogy Mary!


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck
      Sent: 02 September 2005 16:06
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] WIP

      I imagine that managers who get out the whip are the same folks who honk
      their horns in a traffic jam.  Maybe they should check out their whip on
      servers loaded to 90% capacity and see if it helps move transactions trough
      any faster.  Or try it in a security line at an airport....

      Mary Poppendieck
      www.poppendieck.com
      952-934-7998
      Author of:  Lean Software Development: An Agile Toolkit
    • mwpolen
      While I agree that cycle time (the time from customer request to customer fulfillment) is the most important measure I do wonder how you can get any software
      Message 2 of 27 , Sep 4, 2005
      • 0 Attachment
        While I agree that cycle time (the time from customer request to
        customer fulfillment) is the most important measure I do wonder how
        you can get any software organization to buy into it. I have found
        that simple elegant measures, really anything simple, to be too
        simple for the people with the $BIG$. The people in charge seem to
        think "hey if it really was that simple everyone of my peers would
        be doing it this way...NAH this can't work it's a complicated job
        and complicated jobs require complicated ______" In this can
        measurement is the fill in the blank.

        So how do the people in group handle my perceived conundrum?

        -Mike

        ------------------------------------
        "I have opinions of my own -- strong opinions -- but I don't always
        agree with them."
        - George Bush

        http://mwpolen.blogspot.com/
        ------------------------------------
        --- In scrumdevelopment@yahoogroups.com, "Mary Poppendieck"
        <mary@p...> wrote:
        > Actually, I don't think that WIP is the important measurement
        here - cycle
        > time is the standard Lean measurement. You can start and stop the
        cycle
        > time clock whenever you want (accepted story to tests passed, for
        example),
        > depending on what cycle really counts. However, most Lean
        companies measure
        > cycle time from customer order to delivery of order, since the
        focus is on
        > delivering customer value as fast as possible. Thus a software
        organization
        > taking a customer perspective would measure cycle time from
        customer request
        > to deployed feature. An organization with a service level
        agreement, for
        > example, does this routinely.
        >
        > Of course, there are usually more requests than a software
        development
        > organization has the capacity to fill, so there needs to be a way
        to
        > distinguish between work that is within the capacity of the
        organization and
        > work that just can't be accommodated. But still, IMHO, if an
        organization
        > cares about customer response time, the cycle time of the accepted
        requests
        > would be measured from the time the customer placed the request
        (not when it
        > was accepted) until the time the software to satisfy the request is
        > deployed.
        >
        > It is usually beyond the capability of a development team to limit
        the
        > amount of work in its queue, but it is not beyond the capability
        of the
        > management team to do so. A measurement of the cycle time from
        request to
        > deployment does an good job of encouraging an organization's
        management to
        > limit the amount of work it accepts to its capacity to respond.
        When this
        > happens, customer requests flow through the system much faster,
        and this can
        > result in a significant competitive advantage.
        >
        > Mary Poppendieck
        > www.poppendieck.com
        > 952-934-7998
        > Author of: Lean Software Development: An Agile Toolkit
      • Jeff Sutherland
        An issue that is a lot more important than WIP is whether what is in the queue is in the right priority order or is even worth doing. For companies with big
        Message 3 of 27 , Sep 4, 2005
        • 0 Attachment
          An issue that is a lot more important than WIP is whether what is in
          the queue is in the right priority order or is even worth doing. For
          companies with big bucks ready to do a lot of analysis, they should
          use Software by Numbers:
          http://www.amazon.com/exec/obidos/tg/detail/-/0131407287/002-3446661-8579227

          Denne and Cleland-Huang show that unless you systematically forecast
          cost vs. revenue vs. time for each item in the product backlog you
          will lose at least 25% of the potential revenue and in some cases up
          to 400% of the achievable revenue.

          There is also the issue that 45% of the WIP on the average should
          never be built. A Software by Numbers analysis will do enough
          micro-costing of the product backlog that it should flush most of this
          out.

          People should always start with:

          1. Avoid doing this - where's the revenue time line?
          2. Given the revenue time line, is this the most important thing to do now?

          Software by Numbers nicely factors in architectural change and
          maintenance into the revenue stream, something most other methods
          avoid or do poorly leading to revenue loss.

          Without answers to these questions you should always do nothing with
          the WIP. Every line of code you write you will maintain for the rest
          of your working life (or some poor proxy will maintain it). When it is
          useless code, it is an Albatross that you will wear forever. Be
          extreme and avoid coding at all costs.

          Jeff Sutherland

          On 9/4/05, mwpolen <mwpolen@...> wrote:
          > While I agree that cycle time (the time from customer request to
          > customer fulfillment) is the most important measure I do wonder how
          > you can get any software organization to buy into it. I have found
          > that simple elegant measures, really anything simple, to be too
          > simple for the people with the $BIG$. The people in charge seem to
          > think "hey if it really was that simple everyone of my peers would
          > be doing it this way...NAH this can't work it's a complicated job
          > and complicated jobs require complicated ______" In this can
          > measurement is the fill in the blank.
          >
          > So how do the people in group handle my perceived conundrum?
          >
          > -Mike
        • Mike Dwyer
          Thanks for the cite Jeff. Question. How do people handle windows of opportunity ? Since we are living in a world where a product, feature or function can go
          Message 4 of 27 , Sep 4, 2005
          • 0 Attachment
            Thanks for the cite Jeff. Question.

            How do people handle 'windows of opportunity'? Since we are living in a
            world where a product, feature or function can go from innovative to
            commodity in a matter of months, how do you factor in the time it takes you
            to get to market and the time you have in the market before you are copied
            or superceded.

            This pushes the revenue argument to the next level stating that a long ROI
            may in fact be counter productive.

            Michael F. Dwyer

            "Planning constantly peers into the future for indications as to where a
            solution may emerge."
            "A Plan is a complex situation, adapting to an emerging solution."

            -----Original Message-----
            From: scrumdevelopment@yahoogroups.com
            [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jeff Sutherland
            Sent: Sunday, September 04, 2005 2:10 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Re: WIP

            An issue that is a lot more important than WIP is whether what is in
            the queue is in the right priority order or is even worth doing. For
            companies with big bucks ready to do a lot of analysis, they should
            use Software by Numbers:
            http://www.amazon.com/exec/obidos/tg/detail/-/0131407287/002-3446661-8579227

            Denne and Cleland-Huang show that unless you systematically forecast
            cost vs. revenue vs. time for each item in the product backlog you
            will lose at least 25% of the potential revenue and in some cases up
            to 400% of the achievable revenue.

            There is also the issue that 45% of the WIP on the average should
            never be built. A Software by Numbers analysis will do enough
            micro-costing of the product backlog that it should flush most of this
            out.

            People should always start with:

            1. Avoid doing this - where's the revenue time line?
            2. Given the revenue time line, is this the most important thing to do now?

            Software by Numbers nicely factors in architectural change and
            maintenance into the revenue stream, something most other methods
            avoid or do poorly leading to revenue loss.

            Without answers to these questions you should always do nothing with
            the WIP. Every line of code you write you will maintain for the rest
            of your working life (or some poor proxy will maintain it). When it is
            useless code, it is an Albatross that you will wear forever. Be
            extreme and avoid coding at all costs.

            Jeff Sutherland

            On 9/4/05, mwpolen <mwpolen@...> wrote:
            > While I agree that cycle time (the time from customer request to
            > customer fulfillment) is the most important measure I do wonder how
            > you can get any software organization to buy into it. I have found
            > that simple elegant measures, really anything simple, to be too
            > simple for the people with the $BIG$. The people in charge seem to
            > think "hey if it really was that simple everyone of my peers would
            > be doing it this way...NAH this can't work it's a complicated job
            > and complicated jobs require complicated ______" In this can
            > measurement is the fill in the blank.
            >
            > So how do the people in group handle my perceived conundrum?
            >
            > -Mike



            To Post a message, send it to: scrumdevelopment@...
            To Unsubscribe, send a blank message to:
            scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links
          • Steven Gordon
            When the numbers indicate that we should not be implementing a particular feature today, that does not mean that the numbers might not change in 3 months, 6
            Message 5 of 27 , Sep 4, 2005
            • 0 Attachment
              When the numbers indicate that we should not be implementing a particular feature today, that does not mean that the numbers might not change in 3 months, 6 months, or a year from now.  
               
              Doing the requisite analysis to project the value of a feature over time is not free, so there is a tendency to not redo them every quarter.  Or worse, when updating the calculations, not taking the time to questioning whether an assumption that made sense when the value was first calcuated still makes sense today.
               
              So, when the numbers tell us not to implement a feature this quarter, should we tell the customer:
              1. The feature will not be done this quarter, but we will keep it on our backlog and look at it again next quarter, or
              2. The feature will not be done now and we will therefore remove it from our backlog - you can resubmit it next quarter if you think it makes sense then.
               
              The second one reduces cycle time at the expense of forcing the customer to resubmit feature requests periodically.  I prefer the first, but I am not the customer.
               
              One instance where I am a customer is when I submit a resume for a job.  If the response is that I am not a good fit for any of their current openings, I would rather that they keep my application on file than to ask me to resubmit my application whenever I think they might have some new openings that I would fit.
               
              Steven Gordon
               
              On 9/4/05, Jeff Sutherland <jeff.sutherland@...> wrote:
              An issue that is a lot more important than WIP is whether what is in
              the queue is in the right priority order or is even worth doing. For
              companies with big bucks ready to do a lot of analysis, they should
              use Software by Numbers:
              http://www.amazon.com/exec/obidos/tg/detail/-/0131407287/002-3446661-8579227

              Denne and Cleland-Huang show that unless you systematically forecast
              cost vs. revenue vs. time for each item in the product backlog you
              will lose at least 25% of the potential revenue and in some cases up
              to 400% of the achievable revenue.

              There is also the issue that 45% of the WIP on the average should
              never be built. A Software by Numbers analysis will do enough
              micro-costing of the product backlog that it should flush most of this
              out.

              People should always start with:

              1. Avoid doing this - where's the revenue time line?
              2. Given the revenue time line, is this the most important thing to do now?

              Software by Numbers nicely factors in architectural change and
              maintenance into the revenue stream, something most other methods
              avoid or do poorly leading to revenue loss.

              Without answers to these questions you should always do nothing with
              the WIP. Every line of code you write you will maintain for the rest
              of your working life (or some poor proxy will maintain it). When it is
              useless code, it is an Albatross that you will wear forever. Be
              extreme and avoid coding at all costs.

              Jeff Sutherland

            • David J Anderson
              In my work (and my book) I modeled it as investment. The thinking it up can be time-boxed or controlled in some manner. Answer the question... How much are
              Message 6 of 27 , Sep 6, 2005
              • 0 Attachment
                In my work (and my book) I modeled it as investment. The thinking it
                up can be time-boxed or controlled in some manner. Answer the
                question...

                How much are willing to invest in our next innovative idea?

                This is usually constrained in most companies by the funding for the
                marketing department. One of the challenges is that often cost
                accounting prevents technical people from engaging at an early
                enough stage to improve the quality of the ideas.

                David

                --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                <ronjeffries@X...> wrote:
                > On Tuesday, August 30, 2005, at 1:15:06 PM, David J Anderson wrote:
                >
                > > To my mind, it is clearly not WIP unless it has been started,
                and
                > > that ought to involve a commitment back to the customer
                detailing
                > > when it will be delivered. In manufacturing terms a "due date".
                >
                > > Simply identifying it for the backlog does not count as starting.
                >
                > > The fact that the customer has dreamt it up and considers it
                part of
                > > their value stream is not justification for it becoming WIP. To
                use
                > > the manufacturing term, you could consider it "stock" i.e. it is
                in
                > > inventory, but it isn't WIP until a commitment is made and
                resources
                > > are assigned to work on it.
                >
                > Suppose that thinking it up was costly. Would we still not list it
                > as WIP? I think we would. Perhaps WIP is supposed to be measured in
                > dollars or time, not number of items?
                >
                > Ron Jeffries
                > www.XProgramming.com
                > Example isn't another way to teach, it is the only way to teach.
                > --Albert Einstein
              • David J Anderson
                Dollar Days is all about amplication. It s about improving signal to noise ratio in management accounting. From the perspective of this thread, it is largely
                Message 7 of 27 , Sep 6, 2005
                • 0 Attachment
                  Dollar Days is all about amplication. It's about improving signal to
                  noise ratio in management accounting. From the perspective of this
                  thread, it is largely irrelevant. We're deciding where to start the
                  WIP measurement and the lead time measurement.

                  David


                  --- In scrumdevelopment@yahoogroups.com, "Clarke Ching" <lists@c...>
                  wrote:
                  > Ron wrote:
                  > >Perhaps WIP is supposed to be measured in dollars or time, not
                  number of
                  > items?
                  >
                  > Goldratt recommends using "Dollar-days" to measure WIP in factories -
                  thus
                  > taking into account both time and dollars. I've posted a note below
                  > describing Dollar-Days, which I originally sent to Kent Beck's
                  Software in
                  > Process yahoo group.
                  >
                  >
                Your message has been successfully submitted and would be delivered to recipients shortly.