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

Re: [XP] done?

Expand Messages
  • D. AndrĂ© Dhondt
    The prerequisite to our daily deployment has a lot to do with scope. A couple months ago the power of scope really clicked for one of our team members, and
    Message 1 of 27 , Jul 10, 2006
      The prerequisite to our daily deployment has a lot to do with scope. A
      couple months ago the power of scope really clicked for one of our team
      members, and his focus on delivering just what the customer asked for,
      nothing more, made us go faster. We started moving cards at 25-50% more per
      iteration! We nailed several iterations this way, and then we had a failed
      iteration--it failed miserably. We weren't sure why at first, but then we
      realized it had something to do with the fact that this was the first 'big'
      iteration that focussed only on one application--every one of the previous
      big iterations included changes to several applications. Even up to the
      last few hours of this failed iteration we had thought we'd be able to
      deliver on the cards, but since they all hinged upon the release of one
      application, all the cards for the iteration had been moved over to the
      'waiting to deploy' section of our board and the customer hadn't yet gotten
      any business benefit from the work we'd done.

      In retrospect, the problem seems so obvious. This huge pile of 'waiting to
      deploy' cards amounted to one BIG SCARY release. On the last day of the
      iteration, there was one minor issue that needed to be fixed, but we felt
      like we could fix it quickly. Instead, that issue covered up another, and
      yet another, and so the last day of our iteration became an unhealthy 'code
      and fix' cycle. This particular application was a mix of legacy
      'untestable' code and newly refactored, test-first coding--and the system
      was too big to write UTs for all the legacy code in the current iteration.
      We thought we could just keep an attitude of 'leave it cleaner than it was
      when you got there' with the legacy code, and that would be sufficient.
      It's embarrasing to admit we fell into a code and fix cycle, but we were
      knee-deep in it, stayed late and came in early to fix the issue, and never
      succeeded. When the customer got in to see how it was going, we admitted
      failure with no end in sight. We broke out the known issues into new cards,
      started the new iteration, and continued to address each issue. It took
      another week to realize our biggest mistake was a lack of flow, and yet
      another week to figure out how to deploy parts of this application without
      deploying the whole thing. All in all, this mess caused us 3 weeks of
      failed iterations (we did move other cards, but this one app plagued us the
      entire time, and as a result represented broken promises to deliver
      functionality and therefore failed iterations). Even though we knew what to
      do (theoretically) by the third week, it took a while for us to figure out
      how to release a small part of it at a time. As soon as we could take baby
      steps in deploying, however, we got immediate feedback about whether they
      were in the right direction or not--and with the amount of legacy code out
      there we really needed the feedback of daily releases to find out if our
      changes worked or not. With baby steps, it was also easy to see which one
      represented a mistake...

      An earlier reply to this thread listed some of the strategies we use for
      daily deployments...

      This concept of flow has been really powerful in making it so that at every
      step of the way during an iteration, the customer is getting business
      benefit out of the code we've written. I had heard that some XP web teams
      do daily deploys (and know that some web servers make this possible without
      downtime) and I thought maybe we could do this as well. After seeing the
      benefit of baby step deploys, we decided to try daily deployments (even
      sometimes multiple deployments) so that we'd never end up with a BIG SCARY
      deployment at the end of an iteration. Sometimes we can't release a day's
      work the same day, but there's usually something waiting to deploy, and
      keeping that 'waiting to deploy' pile as small as possible is very helpful.

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.