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

Re: [scrumdevelopment] Re: Keeping cross-cutting tasks visible (without technical stories)

Expand Messages
  • Ron Jeffries
    Hello, banshee858. On Thursday, December 2, 2010, at 2:20:45 PM, ... Very nice! Ron Jeffries www.XProgramming.com We accomplish what we understand. If we are
    Message 1 of 28 , Dec 2, 2010
      Hello, banshee858. On Thursday, December 2, 2010, at 2:20:45 PM,
      you wrote:

      > Have you tried something like this?

      > List all the technical debt stuff on little post-it notes
      > adjacent to the Task Board. When a Product Backlog item (PBI) is
      > selected for a Sprint, look at the technical debt pieces and find
      > the pieces that make sense to finish while working on the PBI.
      > Add those to the scope of work for the PBI and estimate how long
      > it will take to complete the feature and the technical debt pieces.

      > That way you make the technical debt work visible, you can
      > prioritize it and link it to real value.

      Very nice!

      Ron Jeffries
      www.XProgramming.com
      We accomplish what we understand. If we are to accomplish something
      together, we need to understand it together.
    • Adam Sroka
      On Wed, Dec 1, 2010 at 6:39 PM, Malcolm Anderson ... If you were going to make that business decision you would at least want to know: 1) How much am I
      Message 2 of 28 , Dec 2, 2010
        On Wed, Dec 1, 2010 at 6:39 PM, Malcolm Anderson
        <malcolm.b.anderson@...> wrote:
        >
        >
        > There are a lot of reasons for taking on short term
        > technical debt. I use the analogy of the credit card with a 36%
        > interest rate. You do not want to use that card. But there are times
        > when it makes great business sense to use that card in a short term
        > situation.
        >

        If you were going to make that business decision you would at least
        want to know:

        1) How much am I spending?

        2) How much interest will I incur? Over what period of time?

        3) Will I have enough revenue to pay it back?

        When teams voluntarily take on technical debt they rarely (if ever)
        know the answer to even one of these questions.

        The interest we are talking about is much higher than you think. It is
        more analogous to a loan shark than a credit card. I have seen teams
        create enough of a mess in a single two-week Sprint that they were
        never able to fix it. I myself am only able to fix the messes I make
        with a reasonable amount of effort if I do it within a few days. After
        a few weeks the effort is an order of magnitude higher than the
        initial investment.

        < beating a dead horse >
        This is not what the technical debt metaphor was ever intended to
        address. Even when we do the best job possible our understanding of
        the problem evolves over time. We have to go back periodically and
        refactor the code to represent our *current* understanding of the
        problem. If we don't then our understanding and the code will continue
        to diverge until the code becomes very hard to maintain. *That* is
        what technical debt means. Neither Ward Cunningham (the originator of
        the metaphor) nor anyone who understood him ever said that writing
        crappy, untested code is sometimes a good business decision.
        < / beating dead horse >
      • Alan Dayley
        +10 Alan
        Message 3 of 28 , Dec 2, 2010
          +10

          Alan

          On Thu, Dec 2, 2010 at 1:56 PM, Adam Sroka <adam.sroka@...> wrote:
           

          On Wed, Dec 1, 2010 at 6:39 PM, Malcolm Anderson

          > There are a lot of reasons for taking on short term
          > technical debt. I use the analogy of the credit card with a 36%
          > interest rate. You do not want to use that card. But there are times
          > when it makes great business sense to use that card in a short term
          > situation.
          >

          If you were going to make that business decision you would at least
          want to know:

          1) How much am I spending?

          2) How much interest will I incur? Over what period of time?

          3) Will I have enough revenue to pay it back?

          When teams voluntarily take on technical debt they rarely (if ever)
          know the answer to even one of these questions.

          The interest we are talking about is much higher than you think. It is
          more analogous to a loan shark than a credit card. I have seen teams
          create enough of a mess in a single two-week Sprint that they were
          never able to fix it. I myself am only able to fix the messes I make
          with a reasonable amount of effort if I do it within a few days. After
          a few weeks the effort is an order of magnitude higher than the
          initial investment.

          < beating a dead horse >
          This is not what the technical debt metaphor was ever intended to
          address. Even when we do the best job possible our understanding of
          the problem evolves over time. We have to go back periodically and
          refactor the code to represent our *current* understanding of the
          problem. If we don't then our understanding and the code will continue
          to diverge until the code becomes very hard to maintain. *That* is
          what technical debt means. Neither Ward Cunningham (the originator of
          the metaphor) nor anyone who understood him ever said that writing
          crappy, untested code is sometimes a good business decision.
          < / beating dead horse >


        • banshee858
          ... Not my idea - it came from Tobias Mayer. Carlton
          Message 4 of 28 , Dec 3, 2010
            >
            > > List all the technical debt stuff on little post-it notes
            > > adjacent to the Task Board. When a Product Backlog item (PBI) is
            > > selected for a Sprint, look at the technical debt pieces and find
            > > the pieces that make sense to finish while working on the PBI.
            > > Add those to the scope of work for the PBI and estimate how long
            > > it will take to complete the feature and the technical debt pieces.
            >
            > > That way you make the technical debt work visible, you can
            > > prioritize it and link it to real value.
            >
            > Very nice!
            >
            Not my idea - it came from Tobias Mayer.

            Carlton
          • tobias.mayer
            I can t take credit for it either. I first witnessed this with a team I worked with at Business Week in NYC. It emerged from the collective consciousness of
            Message 5 of 28 , Dec 6, 2010
              I can't take credit for it either. I first witnessed this with a team I worked with at Business Week in NYC. It emerged from the collective consciousness of the team. As I recall this is what they did (just expanding on Carlton's description):

              Whenever they found technical debt, or any kind of code problem that needed fixing, they didn't fix it unless it was essential to complete the story they were working on (this took some discipline). Otherwise they wrote a sticky note (a task) and added it to a special box on the visual management wall labeled Technical Debt. This served two purposes: a reminder to the team, and a visual representation to the business of the state of the codebase.

              At any subsequent planning meeting, when the USER-FACING stories were discussed (I don't buy into the concept of "technical stories") someone may remind the team that if such-and-such a story was attempted then certain code debt items called out on the wall would need to be fixed as part of that story. The rule was "no workarounds". This clean up work was then considered as part of the essential work of the story, and the story was estimated accordingly.

              These tasks were NOT part of the backlog, they didn't get prioritized and were never fixed in isolation. Instead, when the story was estimated and committed to, these tasks simply became extra tasks towards the completion of the story. It was very elegant, very simple and it worked well for that team. Code debt got cleaned up when doing so resulted in value to the user.

              And visually everyone could see the results of that clean up: An fast-emptying space on the wall.

              Tobias


              --- In scrumdevelopment@yahoogroups.com, "banshee858" <cnett858@...> wrote:
              >
              > >
              > > > List all the technical debt stuff on little post-it notes
              > > > adjacent to the Task Board. When a Product Backlog item (PBI) is
              > > > selected for a Sprint, look at the technical debt pieces and find
              > > > the pieces that make sense to finish while working on the PBI.
              > > > Add those to the scope of work for the PBI and estimate how long
              > > > it will take to complete the feature and the technical debt pieces.
              > >
              > > > That way you make the technical debt work visible, you can
              > > > prioritize it and link it to real value.
              > >
              > > Very nice!
              > >
              > Not my idea - it came from Tobias Mayer.
              >
              > Carlton
              >
            • Ron Jeffries
              Hello, Tobias, Excellent! Just what I like to see! R On Monday, December 6, 2010, at 1:51:46 PM, ... Ron Jeffries www.XProgramming.com In times of stress, I
              Message 6 of 28 , Dec 6, 2010
                Hello, Tobias,

                Excellent! Just what I like to see!

                R

                On Monday, December 6, 2010, at 1:51:46 PM,
                you wrote:

                > I can't take credit for it either. I first witnessed this with a
                > team I worked with at Business Week in NYC. It emerged from the
                > collective consciousness of the team. As I recall this is what
                > they did (just expanding on Carlton's description):

                > Whenever they found technical debt, or any kind of code problem
                > that needed fixing, they didn't fix it unless it was essential to
                > complete the story they were working on (this took some
                > discipline). Otherwise they wrote a sticky note (a task) and added
                > it to a special box on the visual management wall labeled
                > Technical Debt. This served two purposes: a reminder to the team,
                > and a visual representation to the business of the state of the codebase.

                > At any subsequent planning meeting, when the USER-FACING stories
                > were discussed (I don't buy into the concept of "technical
                > stories") someone may remind the team that if such-and-such a
                > story was attempted then certain code debt items called out on the
                > wall would need to be fixed as part of that story. The rule was
                > "no workarounds". This clean up work was then considered as part
                > of the essential work of the story, and the story was estimated accordingly.

                > These tasks were NOT part of the backlog, they didn't get
                > prioritized and were never fixed in isolation. Instead, when the
                > story was estimated and committed to, these tasks simply became
                > extra tasks towards the completion of the story. It was very
                > elegant, very simple and it worked well for that team. Code debt
                > got cleaned up when doing so resulted in value to the user.

                > And visually everyone could see the results of that clean up: An fast-emptying space on the wall.



                Ron Jeffries
                www.XProgramming.com
                In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                -- after Mark Vaughn, Autoweek.
              Your message has been successfully submitted and would be delivered to recipients shortly.