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

Re: [scrumdevelopment] Re: WIP

Expand Messages
  • Ron Jeffries
    ... While I agree entirely, Mary, on the notion of cycle time being key, I ve lived through a number of organizations where the management team, faced with a
    Message 1 of 27 , Sep 1, 2005
    • 0 Attachment
      On Wednesday, August 31, 2005, at 8:59:12 AM, Mary Poppendieck wrote:

      > 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.

      While I agree entirely, Mary, on the notion of cycle time being key,
      I've lived through a number of organizations where the management
      team, faced with a long queue in development, would conclude that
      development needs to go faster, and apply the whip.

      It seems to take a somewhat enlightened view to get to the next step
      -- whatever that might be. How do we bring about that enlightenment,
      and get those guys to put down the whip?

      Regards,

      Ron Jeffries
      www.XProgramming.com
      Sorry about your cow ... I didn't know she was sacred.
    • mike.dwyer1@comcast.net
      Ron: Observation: While getting the whip put down it the goal, a tactic that sometimes works is to have management perform self-flagelation by strictly
      Message 2 of 27 , Sep 1, 2005
      • 0 Attachment
        Ron:
        Observation:
        While getting the whip put down it the goal, a tactic that sometimes works is to have management perform self-flagelation by strictly limiting the amount of business assumptions the team and developers in particular can make.
         
        This can done by simply deferring to the business, those business rules that are not well enough understood to be expressed in boolean terms.  Many times the Product Owner (proxies in particular) has been squeezed by management to "use your best judgement" and the team ends up being guided by the product owner's 'best guess' unsupported by management.
         
        This also helps filter out 'wish list' functionality as management can't expect to see what they can't describe or vision well enough to build.
         
         
         
        --
        Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life


        The greatest oak was once a little nut who held its ground. ~Author Unknown
         
        -------------- Original message --------------

        > On Wednesday, August 31, 2005, at 8:59:12 AM, Mary Poppendieck wrote:
        >
        > > 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.
        >
        > While I agree entirely, Mary, on the notion of cycle time being key,
        > I've lived through a number of organizations where the management
        > team, faced with a long queue in development, would conclude that
        > development needs to go faster, and apply the whip.
        >
        > It seems to take a somewhat enlightened view to get to the next step
        > -- whatever that might be. How do we bring about that enlightenment,
        > and get those guys to put down the whip?
        >
        > Regards,
        >
        > Ron Jeffries
        > www.XProgramming.com
        > Sorry about your cow ... I didn't know she was sacred.
        >
        >
        >
        > ------------------------ Yahoo! Groups Sponsor --------------------~-->
        > Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page
        > http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/9EfwlB/TM
        > --------------------------------------------------------------------~->
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        > <*> To visit your group on the web, go to:
        > http://groups.yahoo.com/group/scrumdevelopment/
        >
        > <*> To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        >
        > <*> Your use of Yahoo! Groups is subject to:
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
      • Mary Poppendieck
        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
        Message 3 of 27 , Sep 2, 2005
        • 0 Attachment
          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

          Date: Thu, 1 Sep 2005 07:21:57 -0400
          From: Ron Jeffries <ronjeffries@...>
          Subject: Re: Re: WIP

          While I agree entirely, Mary, on the notion of cycle time being key,
          I've lived through a number of organizations where the management
          team, faced with a long queue in development, would conclude that
          development needs to go faster, and apply the whip.

          It seems to take a somewhat enlightened view to get to the next step
          -- whatever that might be. How do we bring about that enlightenment,
          and get those guys to put down the whip?

          Regards,

          Ron Jeffries
          www.XProgramming.com
          Sorry about your cow ... I didn't know she was sacred.
        • Ron Jeffries
          ... I d love to see that last one. Nothing more fun than seeing some pompous manager strip-searched. ;- I do think that Agile methods give managers some
          Message 4 of 27 , Sep 2, 2005
          • 0 Attachment
            On Friday, September 2, 2005, at 11:06:08 AM, Mary Poppendieck wrote:

            > 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....

            I'd love to see that last one. Nothing more fun than seeing some
            pompous manager strip-searched. ;->

            I do think that Agile methods give managers some controls that can
            actually be effective, and that the whip is pulled out for the same
            reason they blow the horn: it's something they can do to express
            frustration. Doesn't speed up traffic, of course.

            So my question:

            >> It seems to take a somewhat enlightened view to get to the next step
            >> -- whatever that might be. How do we bring about that enlightenment,
            >> and get those guys to put down the whip?

            ... is addressing the notion that measuring cycle time will bring a
            need to light, but that we need more than that to bring the
            organization to a higher level. I'm interested in learning more
            about what people do to turn the whip into something actually
            useful.

            Ron Jeffries
            www.XProgramming.com
            In times of stress, I like to turn to the wisdom of my Portuguese waitress,
            who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
            -- after Mark Vaughn, Autoweek.
          • Mike Dwyer
            Ron wrote: Nothing more fun than seeing some pompous manager strip-searched. ;- You may have the germ of the next generation of television shows. The
            Message 5 of 27 , Sep 2, 2005
            • 0 Attachment
              Ron wrote:
              "Nothing more fun than seeing some pompous manager strip-searched. ;->"

              You may have the germ of the next generation of television shows.

              The Apprentice meets COPS. Imagine the possibilities with Martha and Donald
              versus the TSA. We could find out all about the hair and the ankle
              bracelet.

              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 Ron Jeffries
              Sent: Friday, September 02, 2005 11:19 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] WIP

              On Friday, September 2, 2005, at 11:06:08 AM, Mary Poppendieck wrote:

              > 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....

              I'd love to see that last one. Nothing more fun than seeing some
              pompous manager strip-searched. ;->

              I do think that Agile methods give managers some controls that can
              actually be effective, and that the whip is pulled out for the same
              reason they blow the horn: it's something they can do to express
              frustration. Doesn't speed up traffic, of course.

              So my question:

              >> It seems to take a somewhat enlightened view to get to the next step
              >> -- whatever that might be. How do we bring about that enlightenment,
              >> and get those guys to put down the whip?

              ... is addressing the notion that measuring cycle time will bring a
              need to light, but that we need more than that to bring the
              organization to a higher level. I'm interested in learning more
              about what people do to turn the whip into something actually
              useful.

              Ron Jeffries
              www.XProgramming.com
              In times of stress, I like to turn to the wisdom of my Portuguese waitress,
              who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
              -- after Mark Vaughn, Autoweek.



              To Post a message, send it to: scrumdevelopment@...
              To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...
              Yahoo! Groups Links
            • Ron Jeffries
              ... I d pay to watch The Donald get taken down a notch. You re fired, my ***. You re busted! Ron Jeffries www.XProgramming.com The main reason that testing
              Message 6 of 27 , Sep 2, 2005
              • 0 Attachment
                On Friday, September 2, 2005, at 1:10:01 PM, Mike Dwyer wrote:

                > Ron wrote:
                > "Nothing more fun than seeing some pompous manager strip-searched. ;->"

                > You may have the germ of the next generation of television shows.

                > The Apprentice meets COPS. Imagine the possibilities with Martha and Donald
                > versus the TSA. We could find out all about the hair and the ankle
                > bracelet.

                I'd pay to watch The Donald get taken down a notch. "'You're fired,'
                my ***. You're busted!"

                Ron Jeffries
                www.XProgramming.com
                The main reason that testing at the end of a development cycle finds
                problems is not that problems were put in near the end, it is that
                testing was put off until then.
              • Clarke Ching
                lovely analogy Mary! _____ From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mary Poppendieck Sent: 02 September
                Message 7 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 8 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 9 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 10 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 11 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 12 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 13 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.