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

Re: [XP] Customer not available on deployment date

Expand Messages
  • Ron Jeffries
    ... Either way will probably work just fine if you have agreement among the folks. Ron Jeffries www.XProgramming.com I could be wrong, of course. It s just not
    Message 1 of 8 , Jun 29, 2005
    • 0 Attachment
      On Tuesday, June 28, 2005, at 8:30:11 AM, angrygreg wrote:

      > We have onsite customers and are working against weekly iterations.

      > We just found out that none of our customers will be available for one
      > of those dates.

      > What do I do?

      > I hate to postpone the release a whole week. But just releasing one
      > day later will screw up our velocity metrics, right?

      > Should I tag the release for the scheduled date; and just do the
      > deployment when the customer is available? The problem there is that
      > our acceptance tests aren't automated, so we can't put the user
      > stories at 100% without the user being present.

      > Anyone have any advice?

      Either way will probably work just fine if you have agreement among
      the folks.

      Ron Jeffries
      www.XProgramming.com
      I could be wrong, of course. It's just not the way to bet.
    • SirGilligan
      ... In Planning Extreme Programming it talks about short releases. It then says, Sometimes you can release much more often, maybe every iteration. This can
      Message 2 of 8 , Jun 29, 2005
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "angrygreg" <angrygreg@y...>
        wrote:
        > We have onsite customers and are working against weekly iterations.
        >
        > We just found out that none of our customers will be available for one
        > of those dates.
        >
        > What do I do?
        >
        > I hate to postpone the release a whole week. But just releasing one
        > day later will screw up our velocity metrics, right?
        >
        > Should I tag the release for the scheduled date; and just do the
        > deployment when the customer is available? The problem there is that
        > our acceptance tests aren't automated, so we can't put the user
        > stories at 100% without the user being present.
        >
        > Anyone have any advice?
        >
        > -greg


        In "Planning Extreme Programming" it talks about short releases. It
        then says, "Sometimes you can release much more often, maybe every
        iteration. This can happen for in-house development and also for
        application service providers where your users are distant but using
        thin clients and you have close control over the server... So even if
        you release into production every iteration, still think about planning
        out a release on a quarterly scale. Even though the resulting plan
        isn't very helpful as a predictor of the future, the act of planning
        those longer releases is vital."

        "How do you make sure individual programmers don't overcommit? During
        iteration planning there's pressure to be seen by the team to be doing
        your part. Fear of censure can overwhelm a programmer's experience.
        We use Yesterday's Weather to reduce the chance of this happening
        regularly. Each programmer measures his velocity by tracking his
        accomplishments every iteration. A programmer can only sign up for the
        same number of days' worth of tasks as he completed last iteration.
        There are good reasons to modify this number. If someone is spending
        one week of this three-week iteration on vacation, he will only have
        two-thirds of his velocity available.
        A programmer's velocity is not a measure of productivity, speed, or
        goalkeeping ability. It just says how many tasks he can sign up for.
        One person may have a low velocity because he is naturally optimistic
        when estimating. Another may have a low velocity because he spends a
        lot of time helping other developers. It's more important for a
        programmer to make accurate predictions than for him to reach any
        arbitrary productivity measure. The absolute value of velocity is far
        less important than its predictive capability."

        "When Is the Iteration Done?
        The iteration is done on the date that was set at the beginning. A two-
        week iteration ends in two weeks, no buts. Stories that are done, are
        done. Stories that are not done are deferred to be considered for
        implementation in the next iteration planning meeting.
        When Is a Story Done?
        A story is done when the function of that story is demonstated to the
        customer and the customer agrees that the functionality substantially
        fulfills what is expected."



        So, the iteration is done when ever the "time box" expires.
        It sounds like you are releaseing at the end of each iteration but you
        are not doing in-house development and thus you are suffering for this
        very short release schedule.

        Remember that velocity is to measure how many tasks a developer can
        sign up for. Nothing more than that (that I know of). Maybe you are
        using it differently, maybe not.

        I have been toying with the idea of Non-Uniform Iterations. Kind of
        like NURBs where the /velocity/ of the paramterization varies in each
        segment. I know that it makes the end of iteration different for each
        programmer and so I haven't determined if it is good or bad yet.

        For example: Iteration = 5 days
        The iteration starts on Monday.
        Joe has 5 days available, so his iteration ends on Friday.
        Bill has 3 days vacation, so his iteration ends on the Wednesday
        following the upcoming Friday (or 8 working days later).
        Jane has 5 days, but has to take PTO for one day. She gets done 6
        working days later.

        I am aware that I am digressing from the original topic. Sorry. These
        Non-Uniform Iterations must work in conjunction with "all at once"
        development, like Scrum Continuous Sprints. I am searching for more
        flexibility and realistic development.

        Back to the topic:
        I would tag the release and have the customer check the stories off as
        complete when they get back. I would also do something to avoid this
        problem again. If automated tests are not feasible then change the
        release schedule to meet any changes in customer availability. This
        will probably mean not doing weekly release EVERY time.

        When the customer gets back and checks the release if any stories fail
        then put them into the next iteration and move on. The overall schedule
        will probably slip at this point. But, that is life! ;-)

        Geoff
      Your message has been successfully submitted and would be delivered to recipients shortly.