Xp Trowe Price

We have initiated a trial XP project to see if it will work for us. Our project is a major upgrade to a C++ application framework that has been around our company for a while but is beginning to show signs of age. T. Rowe Price is a leading mutual fund company that has 12 C++/COM applications deployed using this framework on over a thousand desktops.

We have the following resources:

We have the following requirements:

My superior (director of architecture) has approved XP for use on this project. In general our organization favors the RationalUnifiedProcess but we are going to investigate XP to see what it has to offer, especially in light of our organization's past experiences with heavy methodologies. We'll keep our results posted here as we go along. -- DionHinchcliffe

November 16th, 1999:

Project team is assembled and briefed on XP and encouraged to study it over the next few weeks. Everyone either has or is getting Kent Beck's eXtreme Programming Explained. Story card templates have been created for our first UserStory session this afternoon. There's a bit of enthusiasm about doing something new. Overall team attitude good, although there is some grumbling about PairProgramming but it looks like everyone is ready to give it a try. We'll see how our stories come out and go from there.

November 17th, 1999:

We created our stories in a UserStory session and found them to be a bit on the vague side. After much discussion and whiteboarding, we came up with 9 stories that were neither too large nor too small (1-3 weeks). We found this to be a bit on the small side not to mention that users familiar with use cases found stories to be insufficiently descriptive. Other things went better including our iteration planning session today where the schedule was laid out based on risk, depedencies, and developer load. Our first iteration is going to start after Thanksgiving and end on December 19th. I'm letting the developers get up to speed on XP, get their environments set up (tools, CM, etc.), and work out a SpikeSolution or two.

Dion - it may be useful to recall that XP user stories are "promises" for continued conversations. You are supposed to have a user on hand to finalize the story details as the programming progresses. Therefore they should look to be insufficiently descriptive; that would be a consistent reaction. --AlistairCockburn

Alistair - It sounds like we're close to the mark then as far as the stories are concerned. I'll remind the developers that the stories are refined in conjunction with the users as the iterations progress. Now, the next problem we're running into is the fact that this is not really a business application but a framework upon which business apps are built. Our users are actually the developers that use the framework and the stories we've generated are from their perspective. The problem is that much of a framework's functionality is supposed to be invisible (or transparent) to its users and some of the stories aren't even going to be seen by the developers. In that case, we've written the stories from our perspective since we represent the architecture group and these stories help us meet our architectural goals. Is this a valid approach or are we fooling ourselves here? A couple of people feel that this might invalidate the effectiveness of XP on this project. Any thoughts? --DionHinchcliffe

Oog. -- Alistair (liberally translated, means, "I'm out of my depth on this one. Seems you will have to get clarification from Kent or one of the other XP rulemakers.").

In a way it's actually easier if customers are developers, because then you can get them to write your functional tests without having to involve QA qua QA.

As to your UserStories seeming incomplete, I've seen that too. Encourage your customers who want to write UseCase(s) to do so. I'd also encourage eager customers to do paper prototypes of the GUI they want and to suggest DB formats/contents. The trick is to also have them specify Priority and relevant Quality for each UseCase. and meet the 3-Ideal-Week granularity for Scope. Then, for my money, what you have is still a UserStory. At least in my limited experience it doesn't queer the process if customers attach details to their UserStories ahead of time. Trying to stop them doing that is painful! --PeterMerel

Peter - seems to me these frameworks don't have GUIs. And that the customers of the system might not actually be able to play the role of "informed consumer", i.e., know what they want, in what priority order. Also seems that whether they write UseCases or UserStories depends on how close to XP they all want to hew. - MHO, being neither an XP rulemaker nor on the project, Alistair

Well I'm probably getting well ahead of myself, being far from a rulemaker, but I don't see that a GUI is necessary. It's true frameworks tend to focus on completeness, and that makes YAGNI questionable, but still it seems like completeness should evolve naturally from iteration, so perhaps the fact that it's frameworks isn't so bad. This does raise the question, though, of just when to stop iterating and release.

Moreover, from what Dion says, it seems some of the stories on offer aren't driven by customers so much as by anticipation of infrastructure needs. I'm not certain if that's kosher XP - you're right in thinking this calls for a boffin. My best guess is to fight the customer ignorance angle by getting a business app developed alongside the framework project, and use the UserStories of the app to generate stories for the framework. --Peter.

Peter & Alistair - It's true that some of our XP stories aren't driven by a specific customer but the overall functionality of the framework is of value to our company. One of the important new features is the ability to deliver components dynamically from a web server instead of installing the binary on the desktop manually. This is of particular importance to our customers since a one character config file change costs tens of thousands of the dollars to test and deploy nationwide. In this respect the framework is delivering real, testable value to clearly identifiable external customers. In other respects, it is only delivering value to us (the architecture group) or to the organization as a whole by making apps easier to deploy, integrate, and support. Either way, we seem to have testable stories that deliver tangible value and that seems to me to be enough to justify the use of XP. -- DionHinchcliffe

November 29th, 1999

We started the first iteration today and quickly identified a couple of additional stories. Also, our first try at using JUnit was an unqualified success; we had a test case up and running this afternoon to test out the stories complete with spiffy looking output. Not much luck on the PairProgramming so far. I have some experienced developers on the team and they are churning out code pretty quickly and only then inviting a team member to come over and take a look. I'm hoping someone out there has some ideas on how to encourage PairProgramming. In other news, I'm preparing the code integration station this week so that the first stories can be connected together when they're ready. The developers are already asking for a network drive mount for code integration, however, and I'm not sure about this. Suggestions? -- DionHinchcliffe

What happened? Is the project nearing completion, or shouldn't I ask.... -- GerritRiessen

EditText of this page (last edited May 19, 2003) or FindPage with title or text search