Doug might say that designers and users were smoothly co-evolving.
A teacher might say that you went from the concrete to the abstract. Heck, you
let the abstract (generalization) take care of itself.
Nice, commonsense story.
Henry
SNighthawk@aol.com wrote:
> 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.
>
> Thanks,
> ---Sheldon
>
> ======================================================================
> Sheldon Brahms
> snighthawk@aol.com
> www.hastingsresearch.com
> "No pithy quotes today." - anon.
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:06 PDT