Xp Carolina

So many people act like XP has only been done in Smalltalk at Chrysler and that only KentBeck and RonJeffries can and have done it with any success. It's not true. We've been doing XP whenever possible (and sometimes when it's not :-) since late 1998 with incredible success. I'd been following much of the principles of XP for years alone and in teams, rather successfully if I do say so myself. But my success, confidence, and results have taken a quantum leap as I've fully embraced all of the practices (with my own twists on some). Here's another data point for those who think it's only possible in Detroit on payroll projects with RonJeffries and KentBeck...

June 4, 1999

We just finished week 6 of our ExplorationPhase of the XP/Java project I'm leading. We currently have 4 full-time and 2 half-time people (including me as PlayerCoach) actively working on it from the development side: 2.5 people from RoleModelSoftware, and 2.5 people from the client. We've got close to 80 tests running in the first spike of our system and the basic metaphor is basically formed. We've got a bunch of half-baked stories as the customers are not available to drive the stories as much as we'd like. We're getting away with it because we have a domain expert on the team who can answer most of our questions. The customers will be in on the PlanningGame real soon (probably 2 weeks from now). We're pretty confident it will be successful based on our interaction with them so far... less than we'd like but they seem to be well grounded in reality (they always want more but don't dictate what it should take to get it) and available when we need them to clarify stories that our domain expert can't answer.

Last week, before the project manager went on vacation I had a little private chat with him so he could feel free to speak what was on his mind. He has been involved in software development for a good 20+ years and I was a bit concerned that he would have some concerns about things we weren't doing. So, I asked him, "Do you have any concerns about XP, and what are they?". In just under a second he said "None. I have absolutely no reservations about XP". He can't believe how well the system is shaping up and "couldn't be happier with the team dynamics".

I went in thinking I wouldn't push the PairProgramming but rather back down a bit to TwoSetsOfEyes after we forced everyone to do PairProgramming for the first few weeks. After about two weeks, we found ourselves with an odd number of people at times and a lot to do. We'd start off exploring individually, and before you knew it be programming by ourselves... including me. Before the first day this happened was over, DuffOmelia (another member of the RoleModelSoftware team), pointed out that we were starting down a slippery slope. We all agreed and have taken many steps to fix it. There are still occasions where people end up doing something by themselves, but we typically do it by,

• asking permission from another developer who is already been briefed on what we're doing (e.g. "I'm just going to do X and Y, before I go any further I'll call you back over to look at it and take the next steps"), or
• being requested by our PairPartner?, and only in limited quantities (e.g. "Why don't you finish cleaning up these last couple of methods, while I...?").
• TwoPairsWithThreePeople

It's working out great and everyone on the team is holding each other accountable.

We'll probably be adding 2-3 more people in the DevelopmentPhase?, but part of that will be determined as a result of the PlanningGame and several other variables.

We don't have RonJeffries or KentBeck around. Two of the guys are pretty good Java programmers who have a lot of potential, but still green as designers. 1.5 of the client's people are pretty new to programming at all, but bright and motivated. The ProjectManager/Developer is a competent Java programmer. I end up doing a lot of JustInTimeDesign and JustInTimeDesignReview, but I'm certainly not doing all of the design. I'm only there half of the time, and things go well when I'm not.

I'm using the ArchitectAlsoImplements? pattern along with the rest of the principles and practices of XP. I expect that my role in directing the design of the system will diminish over time as the team gets better at it.

One thing we're doing which I think is an improvement on C3 (I'm sure we're doing things which are not as good) is using a custom XP Wiki (with special thanks to WardCunningham who hosts it for a modest fee) as the DynamicProjectRepositoryAndTrackingSystem?. This allows us to augment the code with some limited design documentation (whatever the team feels is necessary) in living form without the burden of document management. We also record the stories there and roll-up the statistics on it. We also record anything the team thinks is worth recording. It's early, but we think that this is going to be the de facto approach for all of the XP projects we do. (We started using this system for our own internal XP projects, too).

I'll add more here over time, and I'll ask my XP teammates to add/subtract/respond to it as time goes on... -- KenAuer

August 21, 1999

We're about to finish the first iteration of the DevelopmentPhase?. We appear to be pretty well on target... one more week to go. Two more people are on the team now, one from the client and one from RoleModelSoftware.

Since there is no official Product Manager or anyone who is "the buck stops here" on requirements, we are a little uncomfortable with our overall development plan. On the other hand, we have some rough cuts at the iterations and the first iteration planning meeting went well. We are getting some good feedback and input from our customer proxies, and everyone is aware that not having a "buck stops here" kind of person is a problem that we must overcome.

Development is going well. We're trying to get a FunctionalTests team together and it's coming a bit slow, but we're making progress.

Lots of people in the organization are excited, and we're getting to talk about our process to other groups (who are asking for it). A few people might have us in their scope, but so far the rest are pretty supportive and excited about what we are doing. -- KenAuer

January 11, 2000

We're starting the 5th iteration of the DevelopmentPhase?. The team is a bit bigger and we're starting to seriously tackle FunctionalTests.

The 2nd iteration wasn't a good one. We missed a lot of estimates and didn't have good closure. The biggest problem we faced was the foolish idea that estimates made by the team (usually by the more experienced developers) were good enough no matter who ended up with the tasks. Obviously we were wrong.

We fixed this in the 3rd iteration and 4th and did pretty well. The 4th was a little further off due to some technical problems getting some 3rd party products to behave well together... otherwise, we're getting much better at our estimates.

We'd like more customer involvement but we have good "unofficial input from people knowledgeable about the customer" which seems to be getting us by and the client is happy enough to not shift priorities.

We constantly have lapses. But they usually don't go more than a day or two before someone notices (too many people working by themselves, not tracking estimates, not staying focused on task) and we make adjustments.

Recently got an influx of new people (who just released the last version of the previous version of this product)... seem to be fitting into the team, but we're not really giving them many tasks yet. They are mostly learning by pairing.

Have made some adjusments in process whenever we seem to be getting bogged down. We're cranking along right now. -- KenAuer

March 2, 1999 [this should be 2000, right?]

After several months of pointing out that we needed a dedicated "buck stops here" customer to the sponsor(s), and pointing out to the development team that we were making too many "business decisions", we've begun to see a significant change. The "designated customer" has been getting much more involved and available and willing to make buck stops here decisions. The developers are even getting used to asking them to make those decisions instead of trying to make them alone when they discover "gotchas". This is great!

We've decided recently to move from 4-week iterations to a modified 2-week iteration... we still have full IterationProgressReports? and FormalIteration? Planning on a 4-week basis. However, at the end of the FormalIterationPlanning?, we focus on what needs to be done first and really just focus on the next 2-weeks. At the end of the TwoWeeks, we have an InformalIterationPlanning? meeting with just the "buck stops here" customer, where we update our tasks and re-plan the next TwoWeeks.

The idea here is that we have found that when we break down stories into too many tasks, we often find we mis-identified some tasks or grossly misestimated them. We are much better with our estimates of WhatWeKnowWeHaveToDoNext?, than WhatWeThinkWeHaveToDoAfterThat?. So, the two-week mini-iterations allow us to work on WhatWeKnowWeHaveToDoNext?, and reduce the temptation to "spin" the results of the iteration (which are always slightly different than what we thought they'd be at the beginning.

Another motivator is that the Developers are much less pressured and tend to perform better. In the past we noticed that developers tended to lose focus at the end of week 2 and the beginning of week 3. They also tended to forget (design) discussions about tasks that were had 3 weeks earlier when they finally got to their later tasks and sometimes panicked ("I don't know how or why I came up with this estimate") and seemed reluctant to seek help right away... they are always ready to seek help when they are doing the original estimating. Now the mini-iteration makes it so they are ready to seek help when they need it most.

FunctionalTesting is moving along slowly but surely. We all know we should have gotten this in place several months ago, but that's water under the bridge. We've come up with a scheme that we think will satisfy the FDA regulatory requirements as it will produce documented evidence of exactly what and why things were tested along with the results. -- KenAuer

April 19, 2001

We're hoping to have a release candidate to the validation department by the end of May. We've made great progress on our acceptance testing framework (JAccept). We've been tracking for awhile now the number of acceptance tests passing and failing. It's been exciting to see the trend going in the right direction. It's also been gratifying to see the acceptance tests catch our mistakes. Our acceptance tests catch many many things unit tests do not identify.

It's been very difficult to convince the customer that a fast release cycle has a number of advantages over the "let's keep adding features until we can't think of anything else to add" approach. This is something we need to work on.

We are convinced that the cost of change is extremely low for this project. We have been able to make drastic changes to the application after 2 years of development. Because of licensing issues with our database vendor, we recently switched to another object oriented database. We're confident things are working because we have unit tests and acceptance tests to catch most things.

-- DuffOmelia