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

50231Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Feb 2, 2011
      Some good points Adam.  We view frameworks a bit differently(but not too much), but that's not the point of this discussion, and I certainly don't want to get sidetracked on that.  lol.

      > Why should the customer pay for a poor technical decision you made somewhere up the line?

      In the scenario I described, I made it clear that one can assume it was a good technical decision.

      I'm not asking anyone to accept a poor technical decision, and I'm also not thinking that the PO is the best authority on whether a technical decision is poor or not.  I do think, though, they are the best authority in Scrum on whether a Product Backlog item provides the intended value or not.
       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      From: Adam Sroka <adam.sroka@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wed, February 2, 2011 6:16:03 PM
      Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

       

      On Wed, Feb 2, 2011 at 3:57 PM, Charles Bradley - Scrum Coach CSM PSM
      I <chuck-lists2@...> wrote:

      >
      >
      >
      > Ron,
      >
      > Thanks for the thorough answer.
      >
      > Let's change the scenario a bit.
      >
      > Now the dev team has decided that it is time to move from one framework that it uses, to another one(I'm going to leave out the reason, but let's assume it's a pretty good technical decision, unless you feel your answer depends on the reason).  They estimate that this will increase the size of new backlog items that exercise code that uses the old framework for a while, as they transition over to the new framework.  Some ramp up time, if you will, on the new framework.  They are not doing a wholesale change.  They are only using the new framework for new backlog items that would normally involve code that exercises the old framework.  I don't know if one would call this incremental refactoring or not.  I'm not sure what to call it.
      >

      It is worth considering what we can do without using a framework for
      exactly this reason (That it can become hard to change.) When we use
      frameworks badly they create more work than they save. I see this
      happen all the time with popular frameworks (Spring. Hibernate.) When
      we use frameworks well we insulate our code from them by abstracting
      out the details so that replacing them is trivial.

      My rule of thumb here is that I don't use frameworks unless they have
      one specific thing that they do really well and that thing is nearly
      exactly what I am trying to do (e.g. JUnit for testing.) Otherwise I
      see adopting the framework as a risk that I am going to get stuck
      along the wrong road somewhere. So, I would just code it myself. Also,
      it becomes fairly easy to incorporate the framework later once you
      determine that what you decided to do is nearly exactly what it does.

      > In the context of Scrum, and based on your previous answer, does the team then just estimate the size of these backlog items taking into account some extra ramp up time for each?
      >

      Yes and no. I would expect them to estimate based on what they think
      it is going to take to complete the item, but I would also expect the
      PO to challenge things that seemed inordinately expensive or that
      weren't obviously valuable.

      > The main theme of many of these scenarios is technical work on the system under development that cannot be successfully sold to the PO as adding enough business value to bring the technical work to the top of the backlog.  Have you ever seen examples of this technical work that cannot be attached to new backlog items, but still should probably be completed for the health of the system under development, or possibly to help increase overall velocity/quality in the future, or possibly some other wise reason?
      >

      "There is your sign," as they say. If you can't sell it to the PO you
      aren't going to sell it to me. Why should the customer pay for a poor
      technical decision you made somewhere up the line? That sounds like
      your problem to me.

      If you were building a house for me and at the last minute you decided
      to install a different kind of roof, would you expect to be able to
      write me a bill for both roofs?

    • Show all 25 messages in this topic