Heya Grant and Doug,
Saw your post and read the piece on O'Reilly, so I thought I'd send out some
of my experiences with this approach. Although we did not call it Extreme
Programming, we used many of these principles in the Collaborative Newsroom
Environment I developed for a media conglomerate in 1999-2000.
The project description was for a newspaper editorial and production
environment. By nature, it needed to be collaborative, so that was designed
in from the beginning. We needed different levels of access privileges, to
separate what reporters could do from what editors could do to the various
files. The workflow would go from the reporters/writers to the editors, who
would do their various editing chores, as well as preliminary page layout and
markup. From there, the jobs passed into the production department and onto
a different platform for page layout and makeup. All through the process,
the environment needed to integrate with the Internet for e-mail and web
browsing. It also needed to integrate with a variety of Associated Press
file servers for news downloads, photos, stocks and other items, so
connectivity was important.
First off, although we had a fairly complex feature set in mind, we followed
the 80/20 rule in what we settled on for the initial release. We figured
that we could always add later, after the system was already in use and there
were productivity gains enjoyed. In other words, we wanted ROI to be quick,
and not waste our time on things that would add little of immediate value.
We also followed the release early and often principle. It kept the activity
pace a little hectic, but it gave us a useful product almost immediately,
without a long development cycle. We would bring new features online as soon
as possible, and send out new releases as soon as they were stable, sometimes
two a week. Learning curve needed to be shallow and natural, so the features
were added in the order that they would be used. It was important that the
software be accessed in a fashion that the staff was already used to in order
to reduce training time, and therefore, cost of implementation.
The development team was kept extremely small, basically only myself and one
other person, whose job was to install and test the releases at the newspaper
as they were made available. This way, we kept a handle on iterations, and
kept the versioning as simple as possible. It also gave us a definite and
useful feedback loop to and from the end users.
When we got feedback on the product, we could make use of that immediately,
without going through unnecessary layers of programmers for implementation.
This allowed for fine tweaking of the way the software operated, particularly
with respect to interface and workflow issues. It also enabled us to stay in
direct contact with the user community, so that the software could meet their
particular needs, and not just be what we thought it should be.
The project was successful enough that it was in use almost immediately, and
allowed for a planned system migration to take place painlessly, and even
ahead of schedule on the production side. The training time was minimal, and
the users had there own particular work abilities enhanced in ways that were
very natural to them. We even wound up having quite a number of features
that were hidden from the users at the beginning, and enabled gradually as
time went on. There was also enough modularity that new features could be
added easily whenever necessary at a later date.
This process worked out extremely well for us in this project. It kept the
work focused and rapid, and created a virtually no downtime process cycle.
Personally, I really liked working this way, as it eliminated many "normal"
distractions, so I was able to be attentive in a very productive way.
Hope that my experience is useful to you.
"No pithy quotes today." - anon.
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:06 PDT