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

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

Expand Messages
  • George Dinwiddie
    ... I ve never seen the product owner put technical debt into the code. I ve also never seen a PO forbid the team from writing code that they can continue to
    Message 1 of 55 , May 1, 2008
    View Source
    • 0 Attachment
      Stephen Bobick wrote:
      > On Thu, May 1, 2008 at 3:12 PM, Kane Mar <kane_sfo@...> wrote:
      >> This is something that I don't agree with because, when projects go bad, I
      >> believe it's everyone's responsibility
      >>
      >
      > That's just not true. I like the analogy of the Team as a Ferrari and
      > the PO as a driver. If the PO drives the Ferrari off the cliff, who
      > is to "blame"? OK, the Team is an animate entity, with members who
      > can speak up, but the fact remains that the Team can make their point
      > about technical debt until they are blue in the face, but if the PO
      > purposely forbids the Team from doing what it takes to reduce the
      > technical debt, then there is a lot more blame to go to the PO - if
      > not *all* the blame.

      I've never seen the product owner put technical debt into the code.
      I've also never seen a PO forbid the team from writing code that they
      can continue to build upon, though I have seen teams that didn't yet
      know how to write code in that fashion.

      I /have/ seen a PO ask a team to cut corners to meet a deadline. That's
      a case where it's really helpful for the team to have someone who's good
      at dealing with other people--and especially helpful to have good
      technical skills such as TDD and refactoring.

      I would /expect/ a PO to forbid a team to go off refactoring without
      simultaneously producing business value.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • 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, 2008
      View Source
      • 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.