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

Re: [scrumdevelopment] Cost of Change

Expand Messages
  • Jeff Sutherland
    The cost of change is a stable environment may be predictable mathematically, but our environments are not stable. Just take yesterday s events in our small
    Message 1 of 1 , Oct 1, 2003
      The cost of change is a stable environment may be predictable
      mathematically, but our environments are not stable. Just take yesterday's
      events in our small development group.

      1. A major partner that OEMs our product wants Websphere 5 working and
      found a bug that forces a change in our product that resulted in a new
      build the same day.

      2. A major customer could no longer add users to their database. The
      backend system is a partner technology that required joint meetings of two
      companies development teams to resolve.

      3. The product manager of the current release under development moved new
      items into the backlog for the current release.

      4. Multiple new clients were signed up that change the priority of
      requirements in the queue for the current release under development.

      5. A developer white paper outlined a holding bin for errors that would
      radically simplify debugging in the field and shield users from problems.
      This will probably be put in the current release.

      6. Our CEO spent a couple of hours with product marketing going through
      usability changes in the user interface that must be in the current release.

      7. Other stuff too detailed to mentioned.

      At the Scrum meeting this morning, all of this was factored into todays
      direction, sending the development path, the way the product with work, the
      customer priorities, and the user experience down a different track than it
      was on yesterday.

      The bottom line is that yesterday's plan is always wrong for today.
      Therefore, it is not changed midstream, wrong things will hit the field and
      the exponential cost of change principle will reap its ugly rewards.

      The cost of continuous change midstream is what must be minimized by agile

      Jeff Sutherland

      At 07:48 PM 9/30/2003, you wrote:
      >Message: 7
      > Date: Tue, 30 Sep 2003 11:30:27 EDT
      > From: acockburn@...
      >Subject: Re: Re: flattened cost of change curve
      >I find it non-stop fascinating that people are so willing to say something
      >that is exactly wrong, and cover it over by saying, "but let's not get
      >into fine
      >details about it." I find this happens in discussions of Liskov Substitution
      >Principle and the exponential cost of change curve. Both are mathematical,
      >therefore are Right or Wrong.
    Your message has been successfully submitted and would be delivered to recipients shortly.