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

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

Expand Messages
  • banshee858
    ... 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
    Message 1 of 28 , Dec 2, 2010
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, Paul Tevis <ptevis@...> wrote:
      >
      > The team I'm on right now is about four months into a Scrum
      > transition, and we're finally starting to deal with technical debt
      > reduction and technical practice improvement. One thing that I'm
      > struggling with is how to make the work that we're doing on these
      > visible to the team, while at the same time keeping our focus on
      > delivering customer value (i.e. doing real stories).
      >
      > My concerns are (1) as soon as we start tracking non-story tasks we'll
      > lose focus on delivering customer value, and (2) if we don't make
      > these sorts of tasks visible, we won't make progress on them at the
      > rate we need to. What are good patterns you've seen for dealing with
      > technical tasks that aren't directly attached to a story (or that cut
      > across multiple stories)?
      >
      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.

      Carlton
    • 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 2 of 28 , Dec 2, 2010
      • 0 Attachment
        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 3 of 28 , Dec 2, 2010
        • 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 4 of 28 , Dec 2, 2010
          • 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 5 of 28 , Dec 3, 2010
            • 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 6 of 28 , Dec 6, 2010
              • 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 7 of 28 , Dec 6, 2010
                • 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.