The TICR project at ARINC (Aeronautical Radio, Inc.) is running using full-scale XP, with the proviso that some of our deliverables are non-code (tho still developed in an XP process).

TICR is a Win32 PC on a bench (and in the field in later releases).  Its job is the testing, installation, and configuration of something called an IAGS or 'groundstation'.  An IAGS is a large rack with a half-dozen separate components, including both vendor-supplied and ARINC-generated software and hardware.  TICR connects to an IAGS over RS-232 (on about a half-dozen separate lines) and Ethernet (over a single line).  All the normal LAN protocols are used, e.g. TFTP, SNMP, and so on.

The program is true-blue Win32:  All the normal Windows semi-standard rules apply.

We are just now (9/1) moving into full-scale XP after a lengthy preparatory phase, involving a lot of spike code, a lot of paperwork (including a justification and explanation of our XP process), and a lot of training.

The app is in C++ using MFC.  Thumbnailed scope:  about 200 classes, roughly 20k lines of code.  The team has four members.  MichaelHill is consulting full-time, and serving two roles.  As a mentor/trainer, he is responsible for showing the team the method, the language, and the environment.  The other three are new to Win32, new to C++, and new to XP.  They have varying degrees of C skill, but are all reasonably competent journeyfolk at programming.

We are running 3-week iterations.  We are keeping engineering tasks extra-small, not allowing any estimates longer than two ideal days.  (This will probably change as the team gains confidence and skills.)  One addition:  an extreme wrap-up at the end of each iteration, including a brief formal code review and an opportunity for us to update our planning.  We have full as-needed access to a key user, but frankly, the lengthy preparatory phase, the crummy existing product, the simple and well-defined task, and the high level of domain expertise, all conspire to reduce our need for more than once-an-iteration contact with the user, and even that is likely to be perfunctory up the first release in early January.

A nice twist:  only one of the three novices has serious exposure to competing methodologies, and none of them have yet been poisoned by the three banditos, so we have very low resistance-to-XP at the team level.  (A good deal more resistance is up the hierarchy, but we benefit from being low project on the totem pole.)

One further variation:  because of the unique situation of having one expert and three novices, a large part of the preparatory phase was spent having the expert create both a) an architectural approach, more detailed than a system metaphor, but far less detailed than a design, and b) about a quarter of the code required to implement that approach.  The code itself was developed using XP principles, but pairing was occasional.  As we have neared the end of the prep, the novices are getting stronger and have been pairing with the expert more regularly.

The key aspect of this project from an architectural point of view:  this a 100% pure-dee moving target, by definition.  IAGS re-releases every quarter.  TICR must be prepared to support all existing releases ''and'' the new release within 3 weeks.  (We do have access to pre-release versions of IAGS, of course, but until its release is final we have only prototypes to steer our parallel development.)  This has a real impact on our attitudes and outlook.  In particular, MichaelHill confesses to a certain amount of premature need creeping into his infrastructure/architectural work.  Still, he claims that he has YAGNI'd out many more elements of code than he's needed in.

Further bulletins as events warrant.

----

Purely personal reactions so far:  '''I LOVE THIS!!!!'''.  This is better faster smarter safer stronger flexible-er code than I have ever produced before, and it is on time and under budget. --MichaelHill