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

50221Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Ron Jeffries
    Feb 2, 2011
    • 0 Attachment
      Hello, charles_bradley_scrum_coach. On Wednesday, February 2,
      2011, at 4:27:20 PM, you wrote:

      > One thing I believe you've advocated in the past is "attaching"
      > refactoring (or other similar activities, I'll just call it
      > refactoring for now, feel free to refine that term as necessary)
      > to new work that comes into the Product Backlog, thus including
      > that refactoring into the estimate. I believe you've made the
      > point also that the "attached work" should be closely related
      > (maybe in the same part of the system) to the new work in order to
      > justify attaching the work.

      Yes. One cleans up the campground one camps in, not some other one.

      > Do you only estimate with the attached work, or do you give the
      > PO two estimates (one with the attached work, another without)?

      I only work in a professional fashion. There is only one correct
      estimate, the one that improves the situation sufficiently to be at
      least a step forward in quality and testing.

      > I think you've also advocated trying to "sell" the business value
      > of the attached work to the PO. What do you advise when the PO
      > doesn't want to do the attached work, but the Dev Team really
      > feels the attached work is justified to help improve future
      > productivity?

      No. I believe it is impossible to sell because they think we will go
      faster if we work in a crappy fashion. As I choose not to work in a
      crappy fashion, and I know no way to sell quality to someone who
      would prefer to buy crap, I give a bit that says how long it's going
      to take me to do the job cleanly.

      Note that I am not going to gold plate anything. I'm going to get
      the job done in a workmanlike fashion and leave the campground
      better than it was.

      There is no need to refactor code I'm not working in ... now, or at
      any time.

      > I'm curious what you advise in this kind of situation, especially
      > when the Dev Team has a strong desire to do the refactoring work
      > but the PO can't be sold.

      Makes me think the team needs to have more confidence in their
      ability to refactor incrementally. Their lack of confidence may be
      well-founded, through lack of experience doing incremental

      The desire to rewrite the SOB is not a desire to refactor. :)

      Ron Jeffries
      That's my opinion and I agree with it. -- Julio Santos
    • Show all 25 messages in this topic