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

Re: [scrumdevelopment] Continuous Stream of Stories

Expand Messages
  • Adam Sroka
    ... I agree. They write them. That is what they call them. I m doing my best to convince them without regressing to telling them what they should do (Not as
    Message 1 of 109 , Jan 27, 2010
    • 0 Attachment
      On Wed, Jan 27, 2010 at 1:52 PM, Ron Jeffries <ronjeffries@...> wrote:
      >
      >
      >
      > Hello, Adam. On Wednesday, January 27, 2010, at 1:24:42 PM, you
      > wrote:
      >
      > > I was describing a dysfunction that I see a lot at my current client
      > > (Who has a half-dozen or so independent Scrum teams.) The particular
      > > dysfunction is that they do things in a fast and dirty way, write a
      > > "technical debt story" on a card, and promise to come back to it. What
      > > usually happens is that they call that technical debt out when they
      > > are going to be in a nearby area of the code, and put a story on their
      > > Sprint backlog for it.
      >
      > As you know, there is in my opinion no such thing as a technical
      > debt story.
      >

      I agree. They write them. That is what they call them. I'm doing my
      best to convince them without regressing to telling them what they
      should do (Not as easy as it sounds.)

      > > I have been trying to convince them that they aren't helping
      > > themselves by putting these things off. However, given that they are
      > > currently doing this, I can see how a Sprint Goal would help to unite
      > > this work and the work that produces value under a common banner. I
      > > also think that moving to single-piece flow would require not doing
      > > this.
      >
      > To the former, yes. To the latter, I don't see why single piece
      > makes a difference.
      >

      Thinking about it, I suppose you are right. The problems this solves
      and the problem I described are probably orthogonal.

      > >> ...
      >
      > > True. My point is that if we don't pay attention to quality when we
      > > first visit it nothing compels us to pay attention when we come back.
      > > I have seen some teams address this with "technical debt stories." I'm
      > > not suggesting that this is a good practice, but it seems to be common
      > > and it seems to not fit in with the idea of single-piece flow
      > > (Although, come to think of it, it isn't that different from Joshua
      > > Kerievsky's "Refactoring Pause," and he is a big proponent of
      > > single-piece flow in XP.)
      >
      > It is a terrible idea but the number of pieces doesn't play in as
      > far as I can see.
      >

      I think you are right. I think I was mistaken. I still won't recommend
      moving to more frequent deliveries until I can convince them that
      temporary crap smells the same as any other crap ;-) But, I agree that
      this is not an issue of dependency.
    • Adam Sroka
      ... I agree. They write them. That is what they call them. I m doing my best to convince them without regressing to telling them what they should do (Not as
      Message 109 of 109 , Jan 27, 2010
      • 0 Attachment
        On Wed, Jan 27, 2010 at 1:52 PM, Ron Jeffries <ronjeffries@...> wrote:
        >
        >
        >
        > Hello, Adam. On Wednesday, January 27, 2010, at 1:24:42 PM, you
        > wrote:
        >
        > > I was describing a dysfunction that I see a lot at my current client
        > > (Who has a half-dozen or so independent Scrum teams.) The particular
        > > dysfunction is that they do things in a fast and dirty way, write a
        > > "technical debt story" on a card, and promise to come back to it. What
        > > usually happens is that they call that technical debt out when they
        > > are going to be in a nearby area of the code, and put a story on their
        > > Sprint backlog for it.
        >
        > As you know, there is in my opinion no such thing as a technical
        > debt story.
        >

        I agree. They write them. That is what they call them. I'm doing my
        best to convince them without regressing to telling them what they
        should do (Not as easy as it sounds.)

        > > I have been trying to convince them that they aren't helping
        > > themselves by putting these things off. However, given that they are
        > > currently doing this, I can see how a Sprint Goal would help to unite
        > > this work and the work that produces value under a common banner. I
        > > also think that moving to single-piece flow would require not doing
        > > this.
        >
        > To the former, yes. To the latter, I don't see why single piece
        > makes a difference.
        >

        Thinking about it, I suppose you are right. The problems this solves
        and the problem I described are probably orthogonal.

        > >> ...
        >
        > > True. My point is that if we don't pay attention to quality when we
        > > first visit it nothing compels us to pay attention when we come back.
        > > I have seen some teams address this with "technical debt stories." I'm
        > > not suggesting that this is a good practice, but it seems to be common
        > > and it seems to not fit in with the idea of single-piece flow
        > > (Although, come to think of it, it isn't that different from Joshua
        > > Kerievsky's "Refactoring Pause," and he is a big proponent of
        > > single-piece flow in XP.)
        >
        > It is a terrible idea but the number of pieces doesn't play in as
        > far as I can see.
        >

        I think you are right. I think I was mistaken. I still won't recommend
        moving to more frequent deliveries until I can convince them that
        temporary crap smells the same as any other crap ;-) But, I agree that
        this is not an issue of dependency.
      Your message has been successfully submitted and would be delivered to recipients shortly.