Re[2]: RE: Customer involvement and process improvement

Monday, January 06, 2003, 1:48:49 AM, STEURS Stefan wrote:

> Incremental delivery is something I would advise as well but I have seen and
> still see some problems because you need a customer that is willing and able
> to constantly adopt, adapt and apply.  What I mean is that it is not so
> obvious that your customer is up to dealing with a new release/increment
> every 2 weeks for a very long period of time.  In the particular context
> that I am working in, there are seasonal effects which imply the the
> customer has little or no resources to assign to "evaluate" new increments
> during particular periods and those are the summer period from end of june
> until early september (holidays reduce available resources + our business is
> holiday related and peaks in the same season), and there are big changes in
> airspace/route structure definitions in the low season ( october/november +
> january/february ) which means there is lots of data input to be done.
> Given this cyclical (annual) recurring patterns, we don't have a lot of
> freedom to tell the user when he/she should be looking at the increments we
> would like to deliver.

In our environment the customers also do not necessarily want new
functionality to appear in production every iteration. We create a
"production ready" release every iteration, but we implement into a
customer testing environment rather than production. This environment
runs a parallel of production data (not necessarily full-size
databases). The customer and QA testing folks do any final checks
against this environment. On any date, the customer can say:
"Implement it tomorrow", and we do, because it's already production
ready from the IT perspective.

This arrangement allows the customer to stage releases into
production and spend time "evaluating" at their own pace. If the new
features are urgently needed, they can implement after every
iteration. If not, they sometimes go two or three iterations between
actual production implementations.

> What I also have some trouble with is that XP seems to treat features as if
> they were functionally independent.  I've got a lot of trouble with that
> concept.  E.g. take adding a new "object" to a database.  Most likely this
> object will have associations and corresponding business validation rules
> coming along with it that provide syntactical and semantical correctness
> (not to forget database integrity).  Adding a story that requires a new
> object, or even a new attribute, may seem like a "small incremental issue"
> but I've seen otherwise.  For the sake of business continuity it may be wise
> to couple a few of these changes together to allow a complete and thorough
> "validation" as it will make this validation more efficient and effective.

We've found that "from a coding perspective" features are, in fact,
mostly functionally independent. Of course, you are right that
sometimes multiple stories make sense to implement into production
together. The two stage implementation arrangement allows the customer
to decide when stories ought to be linked together. If the stories
completed in iteration 11 don't quite make a complete logical unit of
delivery from the business perspective, the customer simply waits
until the end of iteration 12 to move the new version into "real"
production. Of course, the customer knew at the beginning of iteration
11 that she'd probably wait until after iteration 12.

 Doug Swartz
 [email protected]



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Turn flat surfaces into speakers with the Soundbug.
http://us.click.yahoo.com/QWAVSC/onCFAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/