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

Re: [scrumdevelopment] Re: Critical Chain estimating

Expand Messages
  • mike.dwyer1@comcast.net
    This is another operational flaw in the logical implementation of Buffers. Trust us bald guys, we have been hiding stuff like this for a long time and now you
    Message 1 of 44 , Jul 5, 2005
    • 0 Attachment
      This is another operational flaw in the logical implementation of Buffers.  Trust us bald guys, we have been hiding stuff like this for a long time and now you are faced with the perception that business has that IT and Software could create anything and it would cost nothing.  Please stop it - we goofed.
       
      If you choose to do this covertly, then it will never have value and never be taken into consideration.  I would suggest that you add it into the backlog so that its value can be appreciated (if the work is done) or realized at a later date (when it is done.)
       
      We, as a community, need to better understand how our actions limit the value of what we do.  Get these items into a backlog.  Even if you subscribe to a traditional view of critical chain, there are dependencies, functionality, and quality issues that need to be addressed.
       
      If we were really smart we would begin to tie the various 'enhancement favors' we do as covert engineering to the junk our clients have come to expect from us.
       
      --
      Mike Dwyer

      "I Keep six faithful serving-men
      Who serve me well and true:
      Their names are What and Where and When
      And How and Why and Who." - Kipling
       
      -------------- Original message --------------

      > Isn't it great when this happens :). I like your phrase "repay some
      > technical debt". I've always referred to it as 'covert engineering'.
      >
      > Simon Baker
      >
      >
      > > And in fact we took a good slice of
      > > the buffer back for slack time, which we used to repay some technical
      > > debt. So we gave the Product Owner a bigger increment /and/ we kept
      > > some back for ourselves. I don't think this will become a stick to
      > > beat us with (he said optimistically...)
      > >
      > > Cheers,
      > > Kevin
      > >
      > >
      > > --
      > > http://silkandspinach.net
      >
      >
      >
      >
      > 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/
      >
      >
      >
    • Ron Jeffries
      ... Yes. I think I should have gone above them all, to the CIO. That would have brought the situation to a head, one way or another. ... That s interesting ...
      Message 44 of 44 , Jul 7, 2005
      • 0 Attachment
        On Wednesday, July 6, 2005, at 5:03:19 PM, Simon Baker wrote:

        > The situation you describe is indeed similar. I was both the coach
        > and acting scrummaster. My difficulty was, i couldn't escalate to
        > management because, sadly, they really didn't want to know. They had
        > bigger issues deciding on strategies and company direction. It was a
        > huge time of flux. As i intimated, in the situation a decision had
        > to be made given the bigger picture, and unfortunately i was the
        > only one inline to make it. Ultimately, scrum did fail in this
        > environment because of the politics.

        Yes. I think I should have gone above them all, to the CIO. That
        would have brought the situation to a head, one way or another.

        > As an independent coach, the biggest challenges i encounter usually
        > relate to product owners.

        That's interesting ... how about a new thread on that?

        Ron Jeffries
        www.XProgramming.com
        It is not because things are difficult that we do not dare,
        it is because we do not dare that they are difficult. --Seneca
      Your message has been successfully submitted and would be delivered to recipients shortly.