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

Re: [scrumdevelopment] How to handle design flaw issues during Sprint?

Expand Messages
  • Ron Jeffries
    Hello Paul, thanks for the thoughts quoted here. On Tuesday, ... I truly don t know . It has always been my personal view that improving my skills was
    Message 1 of 19 , Sep 26, 2006
      Hello Paul, thanks for the thoughts quoted here. On Tuesday,
      September 26, 2006, at 1:49:59 AM, you wrote:

      >> spend some time on self improvement, I'm all for that.
      >
      > And that is the interesting topic. How much time, what constraints
      > on topic? Do we allow more time if it will increase team efficiency?
      > etc. etc.

      I truly "don't know". It has always been my personal view that
      improving my skills was primarily my problem, and I have chosen to
      spend a substantial portion of my personal time doing so. Looking
      back over my life, it's hard to regret any of that investment.

      Should the organization allocate time from "its" 40 hours for
      programmers to use in self improvement? Does that really pay off,
      and in what ways? I'm really not sure. I favor the "Gold Card" idea,
      as I mentioned on the refactoring list this morning, but I'm mostly
      just doing it because I believe in it, not because I can measure any
      payoff.

      > Is fixing 'other' smelling code a good candidate (i.e we
      > learn how not to make such a mess next time)?

      It can be. There are serious issues, however. Today, in the presence
      of tests, I could improve some "other" code so quickly that it would
      be more of a coffee break activity and less of a story. On the other
      hand, I've seen teams spend FORTY WORKING DAYS "refactoring" old
      code that would otherwise not have been worked on. That would be not
      so good.

      >> Where is this 6x2+1 thing?
      >
      >From "Agile Estimating and Planning" p.172; Mike Cohn describes
      > a pattern of 6 iterations of 2 weeks duration followed by a 1 week
      > iteration. This 1 week iteration is to relax the strain of constant
      > pressure on the team. During the 1 week iteration "the team chooses
      > its own work"... that is, the team focuses on "what they view as
      > priority work for the project".

      Oh, that. I had forgotten it: I wish the OP had said something that
      would have reminded me, or that I had remembered better, and/or that
      Chet would bring back my copy of Mike's book.

      It's an interesting idea. It seems to me that a little time to
      decompress long before twelve weeks would be a good idea as well.

      Thanks,

      Ron Jeffries
      www.XProgramming.com
      If you want to garden, you have to bend down and touch the soil.
      Gardening is a practice, not an idea.
      -- Thich Nhat Hanh
    Your message has been successfully submitted and would be delivered to recipients shortly.