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

FW: RE: Totally awesome software?

Expand Messages
  • Dave Rooney
    Hello all! ... [Non-text portions of this message have been removed]
    Message 1 of 1 , May 30, 2002
    • 0 Attachment
      Hello all!

      Here is a message I sent to the author of the XP article on Salon.com:

      > -----Original Message-----
      > From: Dave Rooney [mailto:dave.rooney@ [Dave Rooney] <snipped> ]
      > Sent: Thursday, May 30, 2002 6:08 AM
      > To: sam@...
      > Subject: RE: Totally awesome software?
      >
      > Hello!
      >
      > I enjoyed your Salon.com article on Extreme Programming - I thought you
      > gave a very balanced and fair overview of it.
      >
      > I would, however, like to challenge one point you made: "Five years after
      > the fact, the number of XP testimonials trails well behind the number of
      > XP books -- currently numbering more than a dozen on Amazon.com." I
      > realize that the comment was partially tongue-in-cheek, but I felt
      > compelled to respond.
      >
      > I'm a developer doing contract work for the Canadian Government in Ottawa.
      > I have been working in the IT industry for 14 years, and have seen my
      > share of project go over schedule, over budget, ship without all of the
      > promised features, and be riddled with bugs because quality suffered in
      > order to meet a deadline.
      >
      > I was introduced to Extreme Programming (XP) about 18 months ago and,
      > although it was not a religious experience, I felt that I was looking at a
      > better way to deliver software. I read on of "the number of XP books",
      > and did a lot of research on the Web. Something I noticed was that as I
      > read about each of the XP practices, I was saying to myself, "Yeah, we did
      > that on <insert project name here>, and it really worked." I particularly
      > like the concept of embracing change. I have always been very customer
      > oriented which, I suppose, is why I keep getting contracts. Begin able to
      > explicitly state that the customer is allowed to make changes was quite
      > liberating.
      >
      > Just under a year ago, I moved to a new contract, working on a system that
      > had been around since 1998. I arrived just as a new release was being
      > shipped, and everyone was scurrying about in the usual panic to fix
      > last-minute problems in order to get the release out the door. The system
      > did get shipped, owing to the heroics of a few - another day in the
      > trenches.
      >
      > I noticed immediately that the development and client teams were
      > co-located - this is a good thing. Also, the client was already in charge
      > of creating and managing the requirements - another good thing. A few
      > weeks after I arrived, the development team leader moved on to another
      > project and was replaced, purely by chance, by an old friend of mine.
      >
      > I didn't find out until later that the team leader who left was a control
      > freak who insisted that he do all the analysis and simply spewed specs to
      > the developers. To his credit, the design of the system was pretty good.
      > However, there was a terrible communications gap between the developers
      > and the client, despite the fact that they were sitting together. The
      > client never saw the system until it went into user testing after a 6-8
      > month development cycle.
      >
      > I pitched the idea of using XP to the new team leader and to our project
      > manager. They immediately bought into the notion of high levels of
      > communication in XP, and were all for trying it out. "It couldn't be any
      > worse", was one of the comments.
      >
      > We sat down with the client, explained the XP approach, and they were
      > quite enthusiastic. We set about getting the requirements (stories)
      > together for the next release, and providing high-level estimates for the
      > time required. In this particular case, we had an absolute date that
      > certain stories had to be in production. We worked back from that date,
      > accounting for deployment time, etc., and split the stories into
      > iterations.
      >
      > When we set the completion date for the first iteration, I told the client
      > that the date was set in stone, and we would adjust the scope if
      > necessary. They looked skeptical. We then went about breaking the
      > stories into tasks and getting to work on them. It's worth noting that
      > there were 3 developers on this project, so we obviously couldn't use pair
      > programming at all times. Additionally, we didn't use the standard unit
      > testing frameworks because it would have meant changing a lot of existing
      > code, which was deemed to be too much of a risk. We did, however,
      > implement a test utility that allowed us to quickly test the code that was
      > most affected by the changes for this new release. Testing that too 10-15
      > minutes in previous versions of the system now took 5 seconds!
      >
      > While we were developing, we called the client in numerous times to have a
      > look at what we were doing. After all, they were only a few feet away!
      > In previous versions, they weren't even allowed to get screen shots, since
      > "they might change".
      >
      > We met the target date for the first iteration with no difficulty, and
      > gave the client a working version of the system for their testing. A few
      > minor problems surfaced during their acceptance testing, which we fixed
      > right away.
      >
      > We started the second iteration, and actually were ahead of schedule (due
      > mainly to the faster testing turnaround time) when the client called from
      > a meeting with an outside contractor of theirs in Toronto. We were told
      > that a significant chunk of what we were working on was going to have to
      > change. I had checked in the code from the area most affected about half
      > an hour earlier! The client faxed some of the changes from Toronto, and
      > then met with us a day or two later when they returned. We quickly
      > adjusted the stories and tasks to accommodate the changes, and restarted
      > development. We completed the iteration on time, despite the changes, and
      > again the user performed their acceptance testing.
      >
      > Iteration 3 also was completed ahead of schedule, so we were able to add
      > about 10 additional small stories that had been bumped from the original
      > Release Plan. The client tested; we fixed any problems.
      >
      > The client then performed a final, across the board set of acceptance
      > tests for which they scheduled 4 weeks. They were done in 2.5 weeks,
      > including Windows 2000 testing that wasn't originally in the test plan.
      >
      > We packaged the system, and shipped it on the day it had been promised 6
      > months earlier.
      >
      > Throughout the process, the stress level was very low, and team spirits
      > were quite high - we actually had fun!
      >
      > That's my true developer tale of XP! It isn't hype - it really works.
      >
      > Thanks!
      >
      > Dave Rooney
      > Principal Consultant
      > Mayford Technologies
      >
      > E-mail: dave.rooney@ [Dave Rooney] <snipped to discourage
      > spammers!>
      > Web: http://www.mayford.ca
      >


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