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

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

Expand Messages
  • Jason McIntosh
    May 1, 2008
      It seems like making part of a deliverable would work well.  I'm trying to play through how that would go. It seems like you either keep having seemingly simple tasks take a long time because you're unable to pay off technical debt, or you just flat out say "Sure, we'll do that.  But it can't be done until we do x, y, z, techy sounding stuff".  The developers are building the software, they know what it takes.  I think it make sense to just make things part of a story... keep it in a form of : "in order to do user story a, we'll need to do <technical babble> b".

      On Thu, May 1, 2008 at 7:22 PM, Kane Mar <kane_sfo@...> wrote:

      --- In scrumdevelopment@yahoogroups.com, "Stephen Bobick" <sbobick2@...> 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"?

      The usual version of this analogy is that the PO is the navigator and not the drive. I'd
      prefer to move away from analogies because I don't believe it's helpful.

      >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 would suggest that a better approach would be for the team to reduce technical debt by
      leaving all legacy code in better condition than they found it. Over time they will improve
      those parts of the system subject to the most change. Not only that, by doing this they
      don't ask the PO to choose between quality and functionality. There is no question of the
      PO "forbidding" the team from doing what it takes to reduce the technical debt. Just my

    • Show all 55 messages in this topic