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

Refactoring type work in Scrum

Expand Messages
  • Chuck B
    Bennyou/Ron Jeffries(and whoever else wants to comment), From the thread: Break from sprinting - a strategy sprint ... This kind of thing sounds like
    Message 1 of 25 , Feb 2, 2011
    • 0 Attachment
      Bennyou/Ron Jeffries(and whoever else wants to comment),

      From the thread: "Break from sprinting - a strategy sprint"
      > However the old stuff which has been isolated from is starting to get
      clunky, and we want to pre-empt inadequate performance by replacing these. The legacy parts have not been regression tested nor would the
      > effort to regression test the size of this be business feasible and
      this is scaring developers. They are moving away from the hyper-productivity that they are used to and trying to make fixes in area which sees
      > much less visible business value be delivered. Business
      does not understand the slow down of development of features.
       
      This kind of thing sounds like technical debt or something like it (IMO, there is not one really accepted definition of technical debt).

      Ron,

      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.

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

      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.

       -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/

    • Chuck B
      Bennyou/Ron Jeffries(and whoever else wants to comment), From the thread: Break from sprinting - a strategy sprint ... This kind of thing sounds like
      Message 2 of 25 , Feb 2, 2011
      • 0 Attachment
        Bennyou/Ron Jeffries(and whoever else wants to comment),

        From the thread: "Break from sprinting - a strategy sprint"
        > However the old stuff which has been isolated from is starting to get
        clunky, and we want to pre-empt inadequate performance by replacing these. The legacy parts have not been regression tested nor would the
        > effort to regression test the size of this be business feasible and
        this is scaring developers. They are moving away from the hyper-productivity that they are used to and trying to make fixes in area which sees
        > much less visible business value be delivered. Business
        does not understand the slow down of development of features.
         
        This kind of thing sounds like technical debt or something like it (IMO, there is not one really accepted definition of technical debt).

        Ron,

        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.

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

        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.

         -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/

      • charles_bradley_scrum_coach
        Bennyou/Ron Jeffries(and whoever else wants to comment), From the thread: Break from sprinting - a strategy sprint ... This kind of thing sounds like
        Message 3 of 25 , Feb 2, 2011
        • 0 Attachment
          Bennyou/Ron Jeffries(and whoever else wants to comment),

          From the thread: "Break from sprinting - a strategy sprint"
          > However the old stuff which has been isolated from is starting to
          > get clunky, and we want to pre-empt inadequate performance by
          > replacing these. The legacy parts have not been regression tested
          > nor would the
          > effort to regression test the size of this be business feasible and
          > this is scaring developers. They are moving away from the hyper-
          > productivity that they are used to and trying to make fixes in area
          > which sees much less visible business value be delivered. Business
          > does not understand the slow down of development of features.

          This kind of thing sounds like technical debt or something like it (IMO, there is not one really accepted definition of technical debt).

          Ron,

          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.

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

          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?

          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.

          -------
          Charles Bradley, CSM, PSM I
          Experienced Scrum Coach
          My blog: http://scrumcrazy.wordpress.com/
        • charles_bradley_scrum_coach
          So sorry for the triple post. The email from charles_bradley_scrum_coach was my latest and greatest draft of the email I sent, so I hope you ll pay attention
          Message 4 of 25 , Feb 2, 2011
          • 0 Attachment
            So sorry for the triple post.

            The email from "charles_bradley_scrum_coach" was my latest and greatest draft of the email I sent, so I hope you'll pay attention to it.

            [Yahoo Mail is driving me nuts this week! Totally unstable, and when I click on the link to go to "Classic Yahoo Mail", I get a 404 not found type of message. Thanks for nuthin, Yahoo Mail.]

            Charles


            --- In scrumdevelopment@yahoogroups.com, "charles_bradley_scrum_coach" <chuck-lists2@...> wrote:
            >
            > Bennyou/Ron Jeffries(and whoever else wants to comment),
          • Ron Jeffries
            Hello, charles_bradley_scrum_coach. On Wednesday, February 2, ... Yes. One cleans up the campground one camps in, not some other one. ... I only work in a
            Message 5 of 25 , 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
              refactoring.

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

              Ron Jeffries
              www.XProgramming.com
              That's my opinion and I agree with it. -- Julio Santos
            • Charles Bradley - Scrum Coach CSM PSM I
              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
              Message 6 of 25 , Feb 2, 2011
              • 0 Attachment
                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.

                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?

                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?

                (I'm not talking re-writes of major portions of a system here.)(Also, in case you're wondering, I'm not about to advocate the use of the term "Technical Story" or anything like that)
                 
                -------
                Charles Bradley, CSM, PSM I
                Experienced Scrum Coach
                My blog: http://scrumcrazy.wordpress.com/



                From: Ron Jeffries <ronjeffries@...>
                To: scrumdevelopment@yahoogroups.com
                Sent: Wed, February 2, 2011 3:20:05 PM
                Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                 

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

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

                Ron Jeffries
                www.XProgramming.com
                That's my opinion and I agree with it. -- Julio Santos

              • Ron Jeffries
                Hello, Charles. On Wednesday, February 2, 2011, at 6:57:42 PM, ... In the kindest possible way: is there any other approach that could work? If we didn t
                Message 7 of 25 , Feb 2, 2011
                • 0 Attachment
                  Hello, Charles. On Wednesday, February 2, 2011, at 6:57:42 PM,
                  you wrote:

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

                  In the kindest possible way: is there any other approach that could
                  work? If we didn't include this time, wouldn't we fall behind
                  immediately and also ship a new crappy system instead of the old
                  crappy system?

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

                  Only if you are doing something like changing languages. And even
                  then, consider Strangler.

                  > (I'm not talking re-writes of major portions of a system here.)(Also, in case
                  > you're wondering, I'm not about to advocate the use of the term "Technical
                  > Story" or anything like that)

                  Feel free to use them if you want to. And feel free to notice that
                  your Product Owner cannot understand why they're important, and
                  refuses to schedule them.

                  Think in terms of why most of us do not eat right or exercise as we
                  should. Taking October off to get in shape just won't cut it.

                  Ron Jeffries
                  www.XProgramming.com
                  Wisdom begins when we discover the difference between
                  "That makes no sense" and "I don't understand". --Mary Doria Russell
                • Charles Bradley - Scrum Coach CSM PSM I
                  ... Approach 1: Spike Story I think, in some of these situations, you could argue that doing a spike story to get ramped up on the newer framework will help
                  Message 8 of 25 , Feb 2, 2011
                  • 0 Attachment
                    >
                    > > 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?
                    >
                    > In the kindest possible way: is there any other approach that could
                    > work? If we didn't include this time, wouldn't we fall behind
                    > immediately and also ship a new crappy system instead of the old
                    > crappy system?

                    Approach 1:  Spike Story
                    I think, in some of these situations, you could argue that doing a spike story to get ramped up on the newer framework will help remove risk from estimating backlog items that use the new framework.  OTOH, removing large risk and "ramp up time" are not exactly the same thing, so maybe this is not a valid approach.  In this situation, you'd estimate the Spike Story separately.

                    Approach 2:  Dev Item
                    This is where I walk into territory that I'm not terribly comfortable in just yet.

                    Here is one other approach(based on some statements in the Scrum Guide) I've dabbled with in the past when coaching teams.  Maybe I was going off the reservation, or maybe I stumbled onto something interesting.  Not that this approach is not specifically stated in the Scrum Guide, though I think it is a customization within the Scrum Framework that is also consistent with Scrum principles (again as defined in the guide).

                    In the past, I've dabbled with the concept of what I'll call "Dev Items", but there is probably a better term for it.  These "Dev Items" are essentially one or more tasks that the dev team creates in a Sprint Backlog.  These items are often not specifically related to what a specific backlog item describes.  They are more related to how the team decides to create a potentially shippable product increment from the current Product Backlog items.  "...Teams are also self-organizing. No one – not even the ScrumMaster -tells the Team how to turn Product Backlog into increments of shippable functionality..."[Scrum Guide quote]  Further, the dev team defines and makes visible, the "definition of done."

                    As such , as it relates to the "new framework" scenario I've described, if the dev team feels like they need to use a new framework going forward, they can do so whenever they want to, whether or not the PO is ok with it.

                    Interesting notes about Approach #2:
                    1.  I coach dev teams that these dev items MUST be made visible in the Sprint Backlog, and MUST be communicated to the PO.  The amount of time a team spends on Dev Items should be a collaboration/negotiation between the team and PO, but in the end, the dev team makes the final decision.
                    2.  I coach teams that, because these items are not User Stories, they do not count towards velocity.  As such, their velocity might suffer, and that will be made visible and should be discussed openly as well.  This includes accounting for velocity assumptions used for Release Planning, Sprint Planning, etc.
                    3.  Because all of these decision are made visible, dev teams should be careful to only use this time for things that can be well justified to decision makers and whoever ultimately "funds" the team.  If the PO has a direct impact on "funding" the team, then you'd better keep her happy.

                    I don't have this entire thing worked out, and I don't intend to be violating some important tenant of Scrum, either.  If anyone feels as if I am, I'd certainly be interested in your thoughts on the subject.

                     
                    -------
                    Charles Bradley, CSM, PSM I
                    Experienced Scrum Coach
                    My blog: http://scrumcrazy.wordpress.com/



                    From: Ron Jeffries <ronjeffries@...>
                    To: scrumdevelopment@yahoogroups.com
                    Sent: Wed, February 2, 2011 5:14:19 PM
                    Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                     

                    Hello, Charles. On Wednesday, February 2, 2011, at 6:57:42 PM,
                    you wrote:

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

                    In the kindest possible way: is there any other approach that could
                    work? If we didn't include this time, wouldn't we fall behind
                    immediately and also ship a new crappy system instead of the old
                    crappy system?

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

                    Only if you are doing something like changing languages. And even
                    then, consider Strangler.

                    > (I'm not talking re-writes of major portions of a system here.)(Also, in case
                    > you're wondering, I'm not about to advocate the use of the term "Technical
                    > Story" or anything like that)

                    Feel free to use them if you want to. And feel free to notice that
                    your Product Owner cannot understand why they're important, and
                    refuses to schedule them.

                    Think in terms of why most of us do not eat right or exercise as we
                    should. Taking October off to get in shape just won't cut it.

                    Ron Jeffries
                    www.XProgramming.com
                    Wisdom begins when we discover the difference between
                    "That makes no sense" and "I don't understand". --Mary Doria Russell

                  • Adam Sroka
                    On Wed, Feb 2, 2011 at 3:57 PM, Charles Bradley - Scrum Coach CSM PSM ... It is worth considering what we can do without using a framework for exactly this
                    Message 9 of 25 , Feb 2, 2011
                    • 0 Attachment
                      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?
                    • Charles Bradley - Scrum Coach CSM PSM I
                      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
                      Message 10 of 25 , Feb 2, 2011
                      • 0 Attachment
                        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?

                      • Charles Bradley - Scrum Coach CSM PSM I
                        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
                        Message 11 of 25 , Feb 2, 2011
                        • 0 Attachment
                          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?

                        • Adam Sroka
                          On Wed, Feb 2, 2011 at 5:46 PM, Charles Bradley - Scrum Coach CSM PSM ... I think one must assume that it is a poor technical decision given that you had to
                          Message 12 of 25 , Feb 2, 2011
                          • 0 Attachment
                            On Wed, Feb 2, 2011 at 5:46 PM, Charles Bradley - Scrum Coach CSM PSM
                            I <chuck-lists2@...> wrote:
                            >
                            >
                            >
                            > 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 think one must assume that it is a poor technical decision given
                            that you had to completely reverse it in the midst of development.

                            If you had used a crystal ball to see where you were going you would
                            have only chosen the latter framework. Most framework builders assume
                            that you have such a crystal ball, in part because they thought they
                            were using one to write the framework.

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

                            He must be the authority on what has value per se. That is what
                            "Product Owner" means in Scrum. In practice, however, he needs to have
                            a lot of conversations to validate these decisions.

                            He doesn't care about technical decisions and I did not intend to
                            imply that he did. He should be judging what you present him based on
                            the value to the customers/users. Technical decisions are meaningless
                            in this context.

                            He does, however, care about cost. Which means that if you estimate a
                            big cost for a small value based on some technical thing the most
                            reasonable thing for him to do is de-prioritize it accordingly.
                          • Charles Bradley - Scrum Coach CSM PSM I
                            Adam, we don t agree on the framework thing, and I don t care to debate it, so I will concede this line of discussion to you. ... Charles Bradley, CSM, PSM I
                            Message 13 of 25 , Feb 2, 2011
                            • 0 Attachment
                              Adam, we don't agree on the framework thing, and I don't care to debate it, so I will concede this line of discussion to you.
                               
                              -------
                              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:59:26 PM
                              Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                               

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

                              >
                              >
                              >
                              > 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 think one must assume that it is a poor technical decision given
                              that you had to completely reverse it in the midst of development.

                              If you had used a crystal ball to see where you were going you would
                              have only chosen the latter framework. Most framework builders assume
                              that you have such a crystal ball, in part because they thought they
                              were using one to write the framework.

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

                              He must be the authority on what has value per se. That is what
                              "Product Owner" means in Scrum. In practice, however, he needs to have
                              a lot of conversations to validate these decisions.

                              He doesn't care about technical decisions and I did not intend to
                              imply that he did. He should be judging what you present him based on
                              the value to the customers/users. Technical decisions are meaningless
                              in this context.

                              He does, however, care about cost. Which means that if you estimate a
                              big cost for a small value based on some technical thing the most
                              reasonable thing for him to do is de-prioritize it accordingly.

                            • Adam Sroka
                              I understand that you want to discuss the fine point in Scrum and not the premise on which it is founded. However, it is difficult to have a conversation that
                              Message 14 of 25 , Feb 2, 2011
                              • 0 Attachment
                                I understand that you want to discuss the fine point in Scrum and not the premise on which it is founded. However, it is difficult to have a conversation that way, particularly when you think, as I do, that the premise is flawed. 

                                It might be interesting to understand why you think I'm wrong, but if you don't feel like talking about it that is okay. 

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

                                Adam, we don't agree on the framework thing, and I don't care to debate it, so I will concede this line of discussion to you.

                                 
                                -------
                                Charles Bradley, CSM, PSM I
                                Experienced Scrum Coach
                                My blog: http://scrumcrazy.wordpress.com/


                                Sent: Wed, February 2, 2011 6:59:26 PM

                                Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                                 

                                On Wed, Feb 2, 2011 at 5:46 PM, Charles Bradley - Scrum Coach CSM PSM


                                I <chuck-lists2@...> wrote:
                                >
                                >
                                >
                                > 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 think one must assume that it is a poor technical decision given
                                that you had to completely reverse it in the midst of development.

                                If you had used a crystal ball to see where you were going you would
                                have only chosen the latter framework. Most framework builders assume
                                that you have such a crystal ball, in part because they thought they
                                were using one to write the framework.

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

                                He must be the authority on what has value per se. That is what
                                "Product Owner" means in Scrum. In practice, however, he needs to have
                                a lot of conversations to validate these decisions.

                                He doesn't care about technical decisions and I did not intend to
                                imply that he did. He should be judging what you present him based on
                                the value to the customers/users. Technical decisions are meaningless
                                in this context.

                                He does, however, care about cost. Which means that if you estimate a
                                big cost for a small value based on some technical thing the most
                                reasonable thing for him to do is de-prioritize it accordingly.


                              • Charles Bradley - Scrum Coach CSM PSM I
                                Adam, Is there some other technical work that the dev team might think is worthy that PO might not think is worthy(enough to make it into a sprint in the near
                                Message 15 of 25 , Feb 2, 2011
                                • 0 Attachment
                                  Adam,

                                  Is there some other technical work that the dev team might think is worthy that  PO might not think is worthy(enough to make it into a sprint in the near future) that you could substitute here for this discussion?

                                  Some possibilities:
                                  Maybe the dev team would like to fix a legacy bug that really hampers testing, but is not valuable to the PO to make it up to the top of the backlog?
                                  Maybe the dev team would like to enhance their own home grown framework so that it is now easier to use?  Maybe they want to use Java annotations for certain configurations now instead of xml configuration files?
                                  The work to get rid of a framework that was introduced into the system by some person who made a poor technical decision to do so?

                                   -------
                                  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 7:37:45 PM
                                  Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                                   

                                  I understand that you want to discuss the fine point in Scrum and not the premise on which it is founded. However, it is difficult to have a conversation that way, particularly when you think, as I do, that the premise is flawed. 


                                  It might be interesting to understand why you think I'm wrong, but if you don't feel like talking about it that is okay. 

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

                                  Adam, we don't agree on the framework thing, and I don't care to debate it, so I will concede this line of discussion to you.

                                   
                                  -------
                                  Charles Bradley, CSM, PSM I
                                  Experienced Scrum Coach
                                  My blog: http://scrumcrazy.wordpress.com/


                                  Sent: Wed, February 2, 2011 6:59:26 PM

                                  Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                                   

                                  On Wed, Feb 2, 2011 at 5:46 PM, Charles Bradley - Scrum Coach CSM PSM


                                  I <chuck-lists2@...> wrote:
                                  >
                                  >
                                  >
                                  > 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 think one must assume that it is a poor technical decision given
                                  that you had to completely reverse it in the midst of development.

                                  If you had used a crystal ball to see where you were going you would
                                  have only chosen the latter framework. Most framework builders assume
                                  that you have such a crystal ball, in part because they thought they
                                  were using one to write the framework.

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

                                  He must be the authority on what has value per se. That is what
                                  "Product Owner" means in Scrum. In practice, however, he needs to have
                                  a lot of conversations to validate these decisions.

                                  He doesn't care about technical decisions and I did not intend to
                                  imply that he did. He should be judging what you present him based on
                                  the value to the customers/users. Technical decisions are meaningless
                                  in this context.

                                  He does, however, care about cost. Which means that if you estimate a
                                  big cost for a small value based on some technical thing the most
                                  reasonable thing for him to do is de-prioritize it accordingly.


                                • Adam Sroka
                                  On Wed, Feb 2, 2011 at 6:47 PM, Charles Bradley - Scrum Coach CSM PSM ... I doubt it would help. I am not aware of any work that is too technically complex to
                                  Message 16 of 25 , Feb 2, 2011
                                  • 0 Attachment
                                    On Wed, Feb 2, 2011 at 6:47 PM, Charles Bradley - Scrum Coach CSM PSM
                                    I <chuck-lists2@...> wrote:
                                    >
                                    >
                                    >
                                    > Adam,
                                    >
                                    > Is there some other technical work that the dev team might think is worthy that  PO might not think is worthy(enough to make it into a sprint in the near future) that you could substitute here for this discussion?
                                    >

                                    I doubt it would help. I am not aware of any work that is too
                                    technically complex to do incrementally as part of stories but that
                                    can't also be avoided by using a more incremental approach. I suppose
                                    if there were some really hairy mathematical problem that had never
                                    been solved before... but that is such a tiny percentage of the work
                                    out there that I don't believe it is significant in general (It also
                                    tends to be too risky for business to take on. These types of problems
                                    are usually solved by R&D departments or academics and not product
                                    development teams.)

                                    I do encounter teams that get trapped inside their own mental box and
                                    can't find a way to work incrementally (Often frameworks play a part
                                    in that which is why I think they are very relevant.) This is usually
                                    easy to fix, though. It just takes an experienced person gently
                                    revealing the path.

                                    > Some possibilities:
                                    > Maybe the dev team would like to fix a legacy bug that really hampers testing, but is not valuable to the PO to make it up to the top of the backlog?
                                    > Maybe the dev team would like to enhance their own home grown framework so that it is now easier to use?  Maybe they want to use Java annotations for certain configurations now instead of xml configuration files?
                                    > The work to get rid of a framework that was introduced into the system by some person who made a poor technical decision to do so?
                                    >

                                    I could buy the legacy code argument: someone (possibly me) made a
                                    mess and now we have to clean it up. However, if this were a Scrum
                                    team developing a product I would still expect them to seek out value
                                    and only do technical things incrementally and opportunistically. If
                                    it were a maintenance team then maybe that doesn't make sense, but
                                    then neither does Scrum in that situation (IMO.)
                                  • Adam Sroka
                                    ... I just re-read this sentence and realized how awkward it is. What I mean is that I don t believe that we very often find work that has all of the following
                                    Message 17 of 25 , Feb 2, 2011
                                    • 0 Attachment
                                      On Wed, Feb 2, 2011 at 7:21 PM, Adam Sroka <adam.sroka@...> wrote:
                                      > ... I am not aware of any work that is too
                                      > technically complex to do incrementally as part of stories but that
                                      > can't also be avoided by using a more incremental approach. ...

                                      I just re-read this sentence and realized how awkward it is. What I
                                      mean is that I don't believe that we very often find work that has all
                                      of the following qualities:

                                      1) It is purely technical and not related to a specific story
                                      2) It is too big to be subsumed within an existing story, and
                                      3) It cannot be broken down and done in smaller increments as part of stories

                                      If you occasionally see one of these things I would still want to hear
                                      that retrospective, but I don't buy all three at once. All three at
                                      once means you are biting off more than you can chew and you need some
                                      help with technical leadership.
                                    • Ron Jeffries
                                      Hello, Adam. On Wednesday, February 2, 2011, at 10:21:02 PM, you ... Even I would be a bit daunted by changing from .NET to Java. But suppose that the powers
                                      Message 18 of 25 , Feb 3, 2011
                                      • 0 Attachment
                                        Hello, Adam. On Wednesday, February 2, 2011, at 10:21:02 PM, you
                                        wrote:

                                        > I doubt it would help. I am not aware of any work that is too
                                        > technically complex to do incrementally as part of stories but that
                                        > can't also be avoided by using a more incremental approach.

                                        Even I would be a bit daunted by changing from .NET to Java.
                                        But suppose that the powers that be dictated the use of the new
                                        framework and you didn't care to quit.

                                        Ron Jeffries
                                        www.XProgramming.com
                                        Education is the ability to listen to almost anything without losing
                                        your temper or your self-confidence. --Robert Frost
                                      • Ron Jeffries
                                        Hello, Charles. On Wednesday, February 2, 2011, at 8:00:01 PM, ... Yes, though a spike, because its value is also not obvious to the PO, usually needs to be
                                        Message 19 of 25 , Feb 3, 2011
                                        • 0 Attachment
                                          Hello, Charles. On Wednesday, February 2, 2011, at 8:00:01 PM,
                                          you wrote:

                                          >> In the kindest possible way: is there any other approach that could
                                          >> work? If we didn't include this time, wouldn't we fall behind
                                          >> immediately and also ship a new crappy system instead of the old
                                          >> crappy system?

                                          > Approach 1: Spike Story
                                          > I think, in some of these situations, you could argue that doing a spike story
                                          > to get ramped up on the newer framework will help remove risk from estimating
                                          > backlog items that use the new framework. OTOH, removing large risk and "ramp
                                          > up time" are not exactly the same thing, so maybe this is not a valid approach.
                                          > In this situation, you'd estimate the Spike Story separately.

                                          Yes, though a spike, because its value is also not obvious to the
                                          PO, usually needs to be small. I took you to be saying that the
                                          framework was such that it was going to be impacting velocity for a
                                          long time. If so ... that's how long things are going to take, and
                                          I'd estimate them.

                                          If the PO would give me extra time to learn the framework, and you'd
                                          hope to hell they would at least understand that need, then I would
                                          still use that time by building the real features we need, since
                                          that would focus my learning.

                                          I always build new things by starting with a spike of a half-day or
                                          less. I would often just bake it into my estimate.

                                          I do share Adam's concern that the whole framework thing is a bad
                                          idea, especially since the starting premise here is that it's going
                                          to take a long time and slow us down. It's not easy to see why we'd
                                          choose something to slow us down.

                                          I also share his bias that most frameworks do in fact slow us down,
                                          unless they are very specialized. I would use a PDF-writing
                                          framework. I would use OpenGL. I would not use a general application
                                          focused framework unless it was clear that it would speed me up
                                          within the first week or two.

                                          > Approach 2: Dev Item
                                          > This is where I walk into territory that I'm not terribly comfortable in just
                                          > yet.

                                          > Here is one other approach(based on some statements in the Scrum Guide) I've
                                          > dabbled with in the past when coaching teams. Maybe I was going off the
                                          > reservation, or maybe I stumbled onto something interesting. Not that this
                                          > approach is not specifically stated in the Scrum Guide, though I think it is a
                                          > customization within the Scrum Framework that is also consistent with Scrum
                                          > principles (again as defined in the guide).

                                          > In the past, I've dabbled with the concept of what I'll call "Dev Items", but
                                          > there is probably a better term for it. These "Dev Items" are essentially one
                                          > or more tasks that the dev team creates in a Sprint Backlog. These items are
                                          > often not specifically related to what a specific backlog item describes. They
                                          > are more related to how the team decides to create a potentially shippable
                                          > product increment from the current Product Backlog items. "...Teams are also
                                          > self-organizing. No one – not even the ScrumMaster -tells the Team how to turn
                                          > Product Backlog into increments of shippable functionality..."[Scrum Guide
                                          > quote] Further, the dev team defines and makes visible, the "definition of
                                          > done."

                                          No one can put anything into the Sprint Backlog but the Product
                                          Owner, as far as I know. No doubt Dan or someone has another theory.

                                          Note, however, that Scrum can be used to manage anything, including
                                          cutting the grass at the stadium, so it can certainly be used that
                                          way. I do not advise Dev Stories, which sound exactly like Technical
                                          Stories to me, for two important reasons:

                                          As your question reflects, they are difficult for the PO to
                                          prioritize;

                                          All too often, if something is so large that the team wants to
                                          make it a "Dev Item", what is really going on is that they need to
                                          up their game in doing things incrementally. This is also one of
                                          Adam's concerns.

                                          The team can of course break that work into tasks (if they insist on
                                          making the mistake of breaking the work into tasks) and whether they
                                          do so or not, they can choose to do the work by any means necessary,
                                          such as using the framework.

                                          That's what I mean about baking the use of the framework into the
                                          individual stories. If we're going to use the framework on this
                                          story, and it is going to take another day because we're doing it,
                                          then that's the estimate.

                                          > As such , as it relates to the "new framework" scenario I've
                                          > described, if the dev team feels like they need to use a new
                                          > framework going forward, they can do so whenever they want to,
                                          > whether or not the PO is ok with it.

                                          Yes, and bake it into the estimates of the stories / features /
                                          Product Backlog items, however this estimation is done.

                                          > Interesting notes about Approach #2:
                                          > 1. I coach dev teams that these dev items MUST be made visible in the Sprint
                                          > Backlog, and MUST be communicated to the PO. The amount of time a team spends
                                          > on Dev Items should be a collaboration/negotiation between the team and PO, but
                                          > in the end, the dev team makes the final decision.

                                          This makes them sound like there are many items that are discernibly
                                          separate from individual stories. I would prefer not to do that.

                                          > 2. I coach teams that, because these items are not User Stories, they do not
                                          > count towards velocity. As such, their velocity might suffer, and that will be
                                          > made visible and should be discussed openly as well. This includes accounting
                                          > for velocity assumptions used for Release Planning, Sprint Planning, etc.

                                          Yes. I personally believe that they can almost always be avoided.
                                          That said, I completely agree with not counting them as velocity. I
                                          think that Dan, and Roy, and probably others would count them. We've
                                          talked about the pros and cons of that. I would not count them.

                                          > 3. Because all of these decision are made visible, dev teams should be careful
                                          > to only use this time for things that can be well justified to decision makers
                                          > and whoever ultimately "funds" the team. If the PO has a direct impact on
                                          > "funding" the team, then you'd better keep her happy.

                                          Note that in real Scrum the PO has the sole responsibility for
                                          getting the best possible product by the date. Dev stories make her
                                          job much harder, as no one (I mean no one) can properly prioritize
                                          them against a revenue- or benefit-bearing feature.

                                          Since as far as I know it is (almost?) always possible to do the
                                          technical work incrementally, I never recommend Dev Stories as a
                                          strategy.

                                          > I don't have this entire thing worked out, and I don't intend to be violating
                                          > some important tenant of Scrum, either. If anyone feels as if I am, I'd
                                          > certainly be interested in your thoughts on the subject.

                                          I believe the main tenet of Scrum that this impacts is that only the
                                          PO can select things into the Sprint Backlog. While it is true that
                                          the team can build the software using any technical approach they
                                          choose (subject to whatever the company enforces, which is probably
                                          also against a Scrum tenet about self-organization), the necessity
                                          of doing "Dev Stories" raises a very serious question about the
                                          team's ability to execute Scrum well.

                                          Most teams cannot execute Scrum well right out of the box, and in
                                          fact I would bet that most cannot execute Scrum well by my standards
                                          at all. So this is not a fatal flaw, since most Scrum teams probably
                                          get benefit from Scrum.

                                          "Dev Stories" are, however, almost always evidence that the team
                                          would benefit from learning more about working incrementally.

                                          Regards,

                                          Ron Jeffries
                                          www.XProgramming.com
                                          Some things are impossible. And some things people say are
                                          impossible are impossible because they don't know how to do them.
                                          -- Ron Loyd
                                        • Charles Bradley - Scrum Coach CSM PSM I
                                          Let me see if I can address the framework issue, and then we can return to the Dev Items and Scrum. I don t expect Adam to get on board with this at all
                                          Message 20 of 25 , Feb 3, 2011
                                          • 0 Attachment

                                            Let me see if I can address the framework issue, and then we can return to the Dev Items and Scrum.  I don't expect Adam to get on board with this at all because he seems to think that writing a framework is generally better than using a free one that already exists.  Maybe it was my use of the term "framework" that was incorrect, or some other language that bothered him.  I"m not sure.

                                            Let's say you've got a large webapp, with lots of legacy code.  Much of the webapp was built at one time using JSF.  The dev team has decided that going forward, that using Spring MVC, is a better choice.  They also believe that, eventually, this will improve their velocity significantly, for a variety of reasons.  Some of those reasons are that they think Spring MVC is easier and simpler to use.  Another reason is that it's getting harder and harder to find developers with a lot of JFC knowledge, and the industry seems to be trending more toward Spring MVC and similar frameworks/tools.  (Interestingly, Oracle has picked JSF up off of the floor recently, but I still have serious doubts about it) 

                                            As such, the Dev Team works incrementally to begin using Spring MVC for all new stories.  Things go great, and their velocity improves.  However, at some point, there is a relatively small portion of the app that is still using JSF.  That portion of the app is still pretty heavily used by users, but there haven't been a lot of feature requests(User Stories) in that area of the app as of late.  The team loves Spring MVC, thinks it is the way they want to go technically, and wants to convert the last part of the app that still uses JSF.  They estimate it will take about 2 developer weeks to do that, including time for testing, regression testing, etc.  They attempt to sell all of this to the PO.  The PO doesn't really understand the differences between JFC and Spring MVC, and thus doesn't feel like she can prioritize the effort against business value added stories.

                                            Does this help the example or hurt it? 
                                             
                                            -------
                                            Charles Bradley, CSM, PSM I
                                            Experienced Scrum Coach
                                            My blog: http://scrumcrazy.wordpress.com/



                                            From: Ron Jeffries <ronjeffries@...>
                                            To: scrumdevelopment@yahoogroups.com
                                            Sent: Thu, February 3, 2011 1:33:40 AM
                                            Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

                                             

                                            Hello, Charles. On Wednesday, February 2, 2011, at 8:00:01 PM,
                                            you wrote:

                                            >> In the kindest possible way: is there any other approach that could
                                            >> work? If we didn't include this time, wouldn't we fall behind
                                            >> immediately and also ship a new crappy system instead of the old
                                            >> crappy system?

                                            > Approach 1: Spike Story
                                            > I think, in some of these situations, you could argue that doing a spike story
                                            > to get ramped up on the newer framework will help remove risk from estimating
                                            > backlog items that use the new framework. OTOH, removing large risk and "ramp
                                            > up time" are not exactly the same thing, so maybe this is not a valid approach.
                                            > In this situation, you'd estimate the Spike Story separately.

                                            Yes, though a spike, because its value is also not obvious to the
                                            PO, usually needs to be small. I took you to be saying that the
                                            framework was such that it was going to be impacting velocity for a
                                            long time. If so ... that's how long things are going to take, and
                                            I'd estimate them.

                                            If the PO would give me extra time to learn the framework, and you'd
                                            hope to hell they would at least understand that need, then I would
                                            still use that time by building the real features we need, since
                                            that would focus my learning.

                                            I always build new things by starting with a spike of a half-day or
                                            less. I would often just bake it into my estimate.

                                            I do share Adam's concern that the whole framework thing is a bad
                                            idea, especially since the starting premise here is that it's going
                                            to take a long time and slow us down. It's not easy to see why we'd
                                            choose something to slow us down.

                                            I also share his bias that most frameworks do in fact slow us down,
                                            unless they are very specialized. I would use a PDF-writing
                                            framework. I would use OpenGL. I would not use a general application
                                            focused framework unless it was clear that it would speed me up
                                            within the first week or two.

                                            > Approach 2: Dev Item
                                            > This is where I walk into territory that I'm not terribly comfortable in just
                                            > yet.

                                            > Here is one other approach(based on some statements in the Scrum Guide) I've
                                            > dabbled with in the past when coaching teams. Maybe I was going off the
                                            > reservation, or maybe I stumbled onto something interesting. Not that this
                                            > approach is not specifically stated in the Scrum Guide, though I think it is a
                                            > customization within the Scrum Framework that is also consistent with Scrum
                                            > principles (again as defined in the guide).

                                            > In the past, I've dabbled with the concept of what I'll call "Dev Items", but
                                            > there is probably a better term for it. These "Dev Items" are essentially one
                                            > or more tasks that the dev team creates in a Sprint Backlog. These items are
                                            > often not specifically related to what a specific backlog item describes. They
                                            > are more related to how the team decides to create a potentially shippable
                                            > product increment from the current Product Backlog items. "...Teams are also
                                            > self-organizing. No one – not even the ScrumMaster -tells the Team how to turn
                                            > Product Backlog into increments of shippable functionality..."[Scrum Guide
                                            > quote] Further, the dev team defines and makes visible, the "definition of
                                            > done."

                                            No one can put anything into the Sprint Backlog but the Product
                                            Owner, as far as I know. No doubt Dan or someone has another theory.

                                            Note, however, that Scrum can be used to manage anything, including
                                            cutting the grass at the stadium, so it can certainly be used that
                                            way. I do not advise Dev Stories, which sound exactly like Technical
                                            Stories to me, for two important reasons:

                                            As your question reflects, they are difficult for the PO to
                                            prioritize;

                                            All too often, if something is so large that the team wants to
                                            make it a "Dev Item", what is really going on is that they need to
                                            up their game in doing things incrementally. This is also one of
                                            Adam's concerns.

                                            The team can of course break that work into tasks (if they insist on
                                            making the mistake of breaking the work into tasks) and whether they
                                            do so or not, they can choose to do the work by any means necessary,
                                            such as using the framework.

                                            That's what I mean about baking the use of the framework into the
                                            individual stories. If we're going to use the framework on this
                                            story, and it is going to take another day because we're doing it,
                                            then that's the estimate.

                                            > As such , as it relates to the "new framework" scenario I've
                                            > described, if the dev team feels like they need to use a new
                                            > framework going forward, they can do so whenever they want to,
                                            > whether or not the PO is ok with it.

                                            Yes, and bake it into the estimates of the stories / features /
                                            Product Backlog items, however this estimation is done.

                                            > Interesting notes about Approach #2:
                                            > 1. I coach dev teams that these dev items MUST be made visible in the Sprint
                                            > Backlog, and MUST be communicated to the PO. The amount of time a team spends
                                            > on Dev Items should be a collaboration/negotiation between the team and PO, but
                                            > in the end, the dev team makes the final decision.

                                            This makes them sound like there are many items that are discernibly
                                            separate from individual stories. I would prefer not to do that.

                                            > 2. I coach teams that, because these items are not User Stories, they do not
                                            > count towards velocity. As such, their velocity might suffer, and that will be
                                            > made visible and should be discussed openly as well. This includes accounting
                                            > for velocity assumptions used for Release Planning, Sprint Planning, etc.

                                            Yes. I personally believe that they can almost always be avoided.
                                            That said, I completely agree with not counting them as velocity. I
                                            think that Dan, and Roy, and probably others would count them. We've
                                            talked about the pros and cons of that. I would not count them.

                                            > 3. Because all of these decision are made visible, dev teams should be careful
                                            > to only use this time for things that can be well justified to decision makers
                                            > and whoever ultimately "funds" the team. If the PO has a direct impact on
                                            > "funding" the team, then you'd better keep her happy.

                                            Note that in real Scrum the PO has the sole responsibility for
                                            getting the best possible product by the date. Dev stories make her
                                            job much harder, as no one (I mean no one) can properly prioritize
                                            them against a revenue- or benefit-bearing feature.

                                            Since as far as I know it is (almost?) always possible to do the
                                            technical work incrementally, I never recommend Dev Stories as a
                                            strategy.

                                            > I don't have this entire thing worked out, and I don't intend to be violating
                                            > some important tenant of Scrum, either. If anyone feels as if I am, I'd
                                            > certainly be interested in your thoughts on the subject.

                                            I believe the main tenet of Scrum that this impacts is that only the
                                            PO can select things into the Sprint Backlog. While it is true that
                                            the team can build the software using any technical approach they
                                            choose (subject to whatever the company enforces, which is probably
                                            also against a Scrum tenet about self-organization), the necessity
                                            of doing "Dev Stories" raises a very serious question about the
                                            team's ability to execute Scrum well.

                                            Most teams cannot execute Scrum well right out of the box, and in
                                            fact I would bet that most cannot execute Scrum well by my standards
                                            at all. So this is not a fatal flaw, since most Scrum teams probably
                                            get benefit from Scrum.

                                            "Dev Stories" are, however, almost always evidence that the team
                                            would benefit from learning more about working incrementally.

                                            Regards,

                                            Ron Jeffries
                                            www.XProgramming.com
                                            Some things are impossible. And some things people say are
                                            impossible are impossible because they don't know how to do them.
                                            -- Ron Loyd

                                          • Ron Jeffries
                                            Hello, Charles. On Thursday, February 3, 2011, at 8:44:54 AM, you ... Makes it perfect. I can see no business reason whatsoever to make this conversion. If
                                            Message 21 of 25 , Feb 3, 2011
                                            • 0 Attachment
                                              Hello, Charles. On Thursday, February 3, 2011, at 8:44:54 AM, you
                                              wrote:

                                              > As such, the Dev Team works incrementally to begin using Spring MVC for all new
                                              > stories. Things go great, and their velocity improves. However, at some point,
                                              > there is a relatively small portion of the app that is still using JSF. That
                                              > portion of the app is still pretty heavily used by users, but there haven't been
                                              > a lot of feature requests(User Stories) in that area of the app as of late. The
                                              > team loves Spring MVC, thinks it is the way they want to go technically, and
                                              > wants to convert the last part of the app that still uses JSF. They estimate it
                                              > will take about 2 developer weeks to do that, including time for testing,
                                              > regression testing, etc. They attempt to sell all of this to the PO. The PO
                                              > doesn't really understand the differences between JFC and Spring MVC, and thus
                                              > doesn't feel like she can prioritize the effort against business value added
                                              > stories.

                                              > Does this help the example or hurt it?

                                              Makes it perfect. I can see no business reason whatsoever to make
                                              this conversion. If that's the case it should not be done.

                                              The team will argue things like "but if we do it now, changes in
                                              that area will be easier". True, but if you do it later, changes in
                                              that area will also be easier. Therefore, do it later, i.e. when
                                              changes are needed.

                                              It would be fair, and appropriate, to say something like this, if it
                                              were true:

                                              In these areas <list/>, we still have old technology. If we ever
                                              have to do work on these areas, it will cost about N days each
                                              plus however long the actual features take, typically two days. If
                                              we wait until then, changes will require N+2 days. Or, we could do
                                              the prep work now, skipping N days of features now, so that it
                                              would only take two days if and when you need changes over there.

                                              Thing is, when you put it that way, only a fool would approve the
                                              work. And I'd want to question carefully the reasoning of anyone who
                                              made the suggestion.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              If there's only one answer, then this must not be a very interesting topic.
                                            • charles_bradley_scrum_coach
                                              ... In that case, I might say, Depending on how long you wait, N could turn into 1.5N, 2N, or 3N. Right now the team is very quick at doing this conversion
                                              Message 22 of 25 , Feb 3, 2011
                                              • 0 Attachment
                                                > In these areas <list/>, we still have old technology. If we ever
                                                > have to do work on these areas, it will cost about N days each
                                                > plus however long the actual features take, typically two days. If
                                                > we wait until then, changes will require N+2 days. Or, we could do
                                                > the prep work now, skipping N days of features now, so that it
                                                > would only take two days if and when you need changes over there.


                                                In that case, I might say, "Depending on how long you wait, N could turn into 1.5N, 2N, or 3N. Right now the team is very quick at doing this conversion due to the skillset of the team and the fact that we've been doing a lot of this type of conversion lately. As time moves on, the team will most likely lose some of the old technology knowledge or familiarity, so N could turn into 1.3N, 1.5N, 2N, 3N, etc, depending on how long you wait."

                                                Charles
                                              • Ron Jeffries
                                                Hello, charles_bradley_scrum_coach. On Thursday, February 3, ... So despite the fact that this new framework is so wonderful, and the fact that the team will
                                                Message 23 of 25 , Feb 3, 2011
                                                • 0 Attachment
                                                  Hello, charles_bradley_scrum_coach. On Thursday, February 3,
                                                  2011, at 9:35:16 AM, you wrote:

                                                  > In that case, I might say, "Depending on how long you wait, N
                                                  > could turn into 1.5N, 2N, or 3N. Right now the team is very quick
                                                  > at doing this conversion due to the skillset of the team and the
                                                  > fact that we've been doing a lot of this type of conversion
                                                  > lately. As time moves on, the team will most likely lose some of
                                                  > the old technology knowledge or familiarity, so N could turn into
                                                  > 1.3N, 1.5N, 2N, 3N, etc, depending on how long you wait."

                                                  So despite the fact that this new framework is so wonderful, and the
                                                  fact that the team will be working on it all the time in the active
                                                  parts of the product, you are planning to become less capable?

                                                  I'm not buying it.

                                                  Ron Jeffries
                                                  www.XProgramming.com
                                                  Make it real or else forget about it -- Carlos Santana
                                                • Chuck B
                                                  Less capable at the old technology thus making it harder to convert. Sent from my iPhone
                                                  Message 24 of 25 , Feb 3, 2011
                                                  • 0 Attachment
                                                    Less capable at the old technology thus making it harder to convert.

                                                    Sent from my iPhone

                                                    On Feb 3, 2011, at 7:51 AM, Ron Jeffries <ronjeffries@...> wrote:

                                                     

                                                    Hello, charles_bradley_scrum_coach. On Thursday, February 3,
                                                    2011, at 9:35:16 AM, you wrote:

                                                    > In that case, I might say, "Depending on how long you wait, N
                                                    > could turn into 1.5N, 2N, or 3N. Right now the team is very quick
                                                    > at doing this conversion due to the skillset of the team and the
                                                    > fact that we've been doing a lot of this type of conversion
                                                    > lately. As time moves on, the team will most likely lose some of
                                                    > the old technology knowledge or familiarity, so N could turn into
                                                    > 1.3N, 1.5N, 2N, 3N, etc, depending on how long you wait."

                                                    So despite the fact that this new framework is so wonderful, and the
                                                    fact that the team will be working on it all the time in the active
                                                    parts of the product, you are planning to become less capable?

                                                    I'm not buying it.

                                                    Ron Jeffries
                                                    www.XProgramming.com
                                                    Make it real or else forget about it -- Carlos Santana

                                                  • Ron Jeffries
                                                    Hello, Chuck. On Thursday, February 3, 2011, at 9:54:06 AM, you ... It s a story. I m not buying it. I think it would be overselling to say that. But what do
                                                    Message 25 of 25 , Feb 3, 2011
                                                    • 0 Attachment
                                                      Hello, Chuck. On Thursday, February 3, 2011, at 9:54:06 AM, you
                                                      wrote:

                                                      > Less capable at the old technology thus making it harder to convert.

                                                      It's a story. I'm not buying it. I think it would be overselling to
                                                      say that. But what do I know?

                                                      Ron Jeffries
                                                      www.XProgramming.com
                                                      That's my opinion and I agree with it. -- Julio Santos
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.