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

Re: [scrumdevelopment] Cost and Time

Expand Messages
  • J. B. Rainsberger
    ... As you say, zero changes in features doesn t imply zero change, so being agile still has value in responding to /those/ changes, if not feature changes.
    Message 1 of 30 , Jun 26, 2004
    • 0 Attachment
      Ron Jeffries wrote:

      > On Friday, June 25, 2004, at 9:13:22 AM, J. B. Rainsberger wrote:
      >
      >
      >>>>Again: the practices might help the team maximize its velocity, but
      >>>>/being agile/ (preparedness to react to change) seems to be entirely
      >>>>irrelevant on this project.
      >>>
      >>>This would be true if there was only one way to do each feature.
      >
      >>Hm. I don't see why. We don't have to be agile /in philosophy/ to
      >>discuss how to implement each feature and choose an effective way to do
      >>it, do we?
      >
      > No, but you have to be agile /in practice/ to be able to adapt to the
      > alternatives that can be, and will need to be, used to make sure you can
      > ship all the functionality on time.
      >
      > It's fun to imagine that on a project with zero change, we wouldn't need to
      > be agile. But there can't be a project with zero change. We can't stop
      > everyone on the project from learning.

      As you say, zero changes in features doesn't imply zero change, so being
      agile still has value in responding to /those/ changes, if not feature
      changes.

      I'll buy that.
      --
      J. B. Rainsberger,
      Diaspar Software Services
      http://www.diasparsoftware.com :: +1 416 791-8603
      Let's write software that people understand
    Your message has been successfully submitted and would be delivered to recipients shortly.