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

Re: [scrumdevelopment] Cost and Time

Expand Messages
  • Ron Jeffries
    ... 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
    Message 1 of 30 , Jun 25, 2004
    • 0 Attachment
      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.

      Ron Jeffries
      www.XProgramming.com
      Comments lie. Code doesn't.
    • 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 2 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.