Steven,
--- In [EMAIL PROTECTED], Steven Gordon <[EMAIL PROTECTED]> wrote: > Olivier, > > Thanks for this contribution - it is indeed thought provoking, and a magnificent achievement. > Thanks, > A few questions: > - Did you try doing any "pair analysis"? we did not try and force anybody to pair. That happened naturally between some analysts (not all) who decided to work in pairs. The principal beneficial effect I witnessed is the following: when it came to becoming the customer for the XP delivery, one of the analysts who was the truth for the IT team could not come to work for a period of time. The analyst who paired extensively with this person instantly became the customer and the story was delivered. (what I mean here for pairing is that they spent a lot of time together, sitting together, discussing the data collection, consolidation, statistical analysis, recommendation, and that they produced the Customer Story as a pair.). > - Did the work schedule for analysts (i.e., estimated number of stories per XA iteration) > explicitly account for time to be spent as XP Customers? No, the schedule did not state explicitly this. As I say in the presentation (retrospective bit): breaking down outcome stories into analysis tasks was a bit hard to achieve: one of the reasons for this is that it takes time to be good at estimating, and we only ran 3 XA iterations. At the end of the 3 XA iterations, all out customers were available full time. > - How did you assure logical consistency among the Outcome Stories produced by the XA > team (i.e., was there the equivalent of collective ownership of the Outcome Stories)? XA does not produce outcome stories: it needs outcome stories to start (that is what feeds the XA planning game), XA will generate Customer Stories. The senior process architects (in our jargon) were in charge of ensuring the consistency of all Customer Stories produced. We also use a digital tool here to record all stories produced (along with acceptance criteria and value), which everybody has access to. In this respect, you could say that there was collective ownership of a stories. > - Did pushback/questions from the XP team ever result in XA rework on Outcome Stories? I guess you mean Customer Stories produced: absolutely. Like any other member of the team, IT has access to the story repository, and we had sessions to review what was building up in the pot on a weekly basis, we meant that some stories were revisited (changed, broken down, acceptance criteria added or amended). > - Did the XP team misunderstand any requirements due to not working directly with real > customers and users? In one or two instances, yes. However, this was rapidly spotted as we organised show and tell sessions every week were real customers were invited. > > Thanks, > > Steven Gordon > http://sf.asu.edu/ > > > > -----Original Message----- > From: Olivier Lafontan [mailto:[EMAIL PROTECTED] > Sent: Fri 12/3/2004 4:23 AM > To: [EMAIL PROTECTED] > Cc: > Subject: [XP] A Plug-in to XP: XA (eXtreme Analysis) >> case study presentation > > > > > > > Hi everyone, > > I just joined the group after I was recently advised to present some > of my material to this audience. > > Hope you'll find this of interest and that we can get a discussion > going on the subject of "eXtreme Analysis". > > XP and other agile approaches really focus on allowing organisations > to re-organise and re-align their capability to deliver... this > implies that our customer actually knows what they want. > > At the begining of the year, I had to manage a project where no > matter how much of the XP practices we could implement, the project > was going to deliver virtually no business value (but a lot of IT > changes...). > > That makes me say that "XP is really good at delivering what is in > the story pot. If no value is in the story pot, XP will be really > good at delivering no value." > > Being lucky enough to work for an organisation that allows me to > experiment, I have tried a new approach to /save/ this project and > protect the outcome. > > This project now being finished, I have consolidated all this > experience in a Case Study presentation. I presented this material > at XP Day London last month. > > The presentation can be found at > http://groups.yahoo.com/group/extremeprogramming/files/eXtreme% > 20Analysis/ , which is in the file section of this group, under a > new folder called eXtreme Analysis. > > Thanks > > Olivier > > > > > > > > > To Post a message, send it to: [EMAIL PROTECTED] > > To Unsubscribe, send a blank message to: [EMAIL PROTECTED] > > ad-free courtesy of objectmentor.com > Yahoo! Groups Links > > > > > > > > > > > > [Non-text portions of this message have been removed] To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
