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

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

Expand Messages
  • 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 1 of 28 , Dec 2, 2010
    View Source
    • 0 Attachment
      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 2 of 28 , Dec 2, 2010
      View Source
      • 0 Attachment
        +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 3 of 28 , Dec 3, 2010
        View Source
        • 0 Attachment
          >
          > > 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 4 of 28 , Dec 6, 2010
          View Source
          • 0 Attachment
            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 5 of 28 , Dec 6, 2010
            View Source
            • 0 Attachment
              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.