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

Re: [scrumdevelopment] Re: Backlog of technical tasks?

Expand Messages
  • Jim Schiel
    Message 1 of 55 , Apr 30, 2008
    • 0 Attachment
      Really an interesting question....
       
      First of all, let's be careful with HOW we pose this concept. By saying that the teams have to pay down the technical debt, it almost sounds like we're blaming the teams for creating the technical debt in the first place. As far as your scenarios and the implementation planning, you'll generally find that the creation and "grooming" of the product backlog has to occur pretty early in the implementation of Scrum. The first step is to build the product backlog from everything you need to do to the product. Technical debt needs to be part of that backlog and should be prioritized along with everything else.
       
      If the technical debt is "large"...well, that's one of those hard things that we have to recognize during the implementation of Scrum (though I doubt it's really a surprise). Whether there's a little or a lot, your POs will need to work with your architects and/or technical leads to evaluate the technical debt and prioritize it properly. If there's a lot, you may also need to start talking about contingency plans if getting the technical debt done might delay other project deadlines or, conversely, you can't resolve the technical debt fast enough, and a technical dead-end may be headed your way.
       
      Bottom line -- technical debt is no different than anything else on the backlog. Don't treat it like a second class citizen -- it's always going to be there and everyone should get used to it being there.
       
      Jim Schiel
      CST, Danube Technologies, Inc.

      On Wed, Apr 30, 2008 at 10:24 PM, MacKilby <mckilby@...> wrote:

      --- In scrumdevelopment@yahoogroups.com, "Stephen Bobick"
      <sbobick2@...> wrote:
      >
      > If the organization ignores the Team repeatedly - a Team who predicts
      > failure if they aren't listened to regarding technical debt and an
      > unmaintable code base, and the organization drives the Team over a
      cliff,
      > well, why not point that out?
      >
      > -- Stephen

      I'd like to toss in a slightly different scenario. What if the team
      negotiated a "payment plan" to pay down the technical debt with the
      PO? (This would be on a per team basis and I think this was suggested
      earlier). In other words, the PO agrees to take on a certain amount
      of technical debt per sprint as backlog items until the debt was below
      some threshold.

      Now a slightly different scenario... if this is an organization-wide
      rollout of agile processes and the organization realized that it had
      large technical debt across all its projects, what would be the
      implications of mandating the "payment plan" of technical debt across
      the organization? If this seems feasible, when in the agile adoption
      process should this be introduced?

      Mark Kilby



    • Michael James
      ... Yes, and there s really no contradiction between these approaches once we see the Sprint Planning Meeting as a good faith negotiation. Normal technical
      Message 55 of 55 , May 4 3:45 PM
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "Jeppe N. Madsen" <jeppe@...> wrote:

        > I've been skeptical about putting technical tasks on the backlog for
        > many of the same reasons listed in this thread. I think we should
        > make "the world a better place" one step at a time, by refactoring the
        > code as it's touched due to new requirements.

        Yes, and there's really no contradiction between these
        approaches once we see the Sprint Planning Meeting
        as a good faith negotiation.

        Normal technical debt should be paid off through
        the definition of "done" for product feature stories.
        Things like this might include refactoring away
        duplicate code, complex conditional logic, long
        modules, nested "catch" blocks, poorly named
        methods and classes, normal database schema
        changes, normal upgrades to third-party
        libraries....

        > If there really are technical debt that hinders
        > progress, this is an impediment.

        Yes, when progress on multiple fronts is impeded
        by severe fundamental underlying debt issues
        (often at the infrastructure level, like platform
        changes, major database changes, major library
        changes) it may be useful for the team to make
        it visible in the product backlog as a step toward
        breaking the repayment work into manageable
        pieces. Anyone can add items to the Product
        Backlog.

        Of course we still expect some feature delivery
        every Sprint.

        --mj
      Your message has been successfully submitted and would be delivered to recipients shortly.