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

[XP] Re: What to do if tasks not finishing within iteration period?

Expand Messages
  • Martijn Meijering
    Hello Kent, Thanks for your reply, it made me think... ... If flow ... Yes, absolutely. And the situation I m very interested in is when there is a
    Message 1 of 20 , Sep 21, 2007
    • 0 Attachment
      Hello Kent,

      Thanks for your reply, it made me think...

      > When the practices don't work, go back to the values and principles.
      If flow
      > is hard, then make value flow as much as possible and work to smooth the
      > flow in the future.

      Yes, absolutely. And the situation I'm very interested in is when
      there is a disagreement with the client about how to do it. I like to
      believe I know how to develop software and feel very unhappy if I have
      to go back to the bad old ways. I also feel bad if a customer
      overrules me on process issues. I feel that that most managers do not
      know enough about software development to make those decisions.

      So my instinct would be to refuse (to the degree possible given
      legal/moral obligations) to work on stories that are bigger than an
      iteration. You seem to be suggesting a less confrontational approach.
      When I say it like that, it makes sense to me. Is that what you mean?

      And is this largely a matter of effectiveness or preference or even

      >I try not to blame the awful state of the current
      > system, though. I find it works better to make statements about
      myself, "It
      > takes me between 4-8 hours to figure out how the system works
      currently, a
      > day or two to verify that the defects I find are really defects and
      > out which ones to fix, a few minutes to make the change, and 3-4 days to
      > make sure I didn't break anything accidentally." That conveys the same
      > information but in a responsible way.

      That's a very interesting remark. I can see how there is no blame in
      the above. I can also see that saying "it's because of the horrible
      code" is a form of blaming. Not blaming is probably better than
      blaming. I'm trying to understand what exactly you mean by
      responsible. Does it have to do with circle of concern vs circle of

      > If the customer picked a story that would take me three iterations,
      I would
      > explain my estimate, listen to what they said, and try to work out a
      way I
      > could demonstrate progress each week, even if I couldn't ship business
      > value.

      I see. And suppose the customer came to you and asked for advice.
      Should I ask the programmers to work on a story larger than an
      iteration? Or should I choose other, shorter stories and reduce
      technical debt in the process?
    Your message has been successfully submitted and would be delivered to recipients shortly.