We've mopped up most of the rules for the iteration's output documents and have coded the easy ones. We're way ahead of of our estimated progress, so it's time for our business user to add stories.

Since we came so far by dropping out complicated low-volume quotes, we could drop them back in again. Instead, as we've recommended, we're to push on to the next types of quotes.

This will reveal sooner more of the data we need for the mainframe link.

Sidelined analysis of annuity calculations while we find out how much of this we already have coded in other SVQ applications.

Joe started coding up output documents with Sarah and me. We hadn't expected to get here so quickly, so Sarah will take tomorrow morning to assemble a complete set of the output and mark up the variable segments. After an afternoon coding up documents with me, Joe should be able to work up the rest over a couple of days without leaving Hampshire. The limits on co-location: we generally work faster together, but the travel is a burden worth avoiding when we can.

I hear IT wants fully documented requirements for the mainframe link before any build work starts. How to reconcile this with our process? Perhaps we can exploit the 'best seams first' strategy. Since we've tackled the the most valuable processes first, we can specify with some confidence what we need for the first phase and come to some 'best efforts' agreement for a second phase, with perhaps a third phase later to mop up spills.

Back on business rules with Joe sitting in. He started off yesterday by coding non-trivial expressions so I could keep working with Sarah. Yesterday it became clear that his application knowledge is much better than mine, so we switched places.

I'm seeing that with his application knowledge he's able to elicit processing rules with confidence that he and Sarah have understood each other. That's more efficient and less rigorous than my working through test cases until Sarah can't think of any variations we haven't covered. Let's see how we've done when we've got some test cases on file for the new rules.

Set aside coding some of the more complicated rules. Unsurprisingly, they are used infrequently. They also require information we can't grab from the mainframe, thus need GUI objects to get from user. Chose to defer spending project budget on these: we can always come back later.

Roger wins the mainframe interface sweepstake! His was the most optimistic date (30 April) and closest to the date work started (29 April). He gets to pick the charity the stakes get donated to.

Met our mainframe interface programmer today, and we got aligned on a lightweight approach. Once we'd relaxed a bit, she saw that she could meet our request for a 'spike' interface simply by finding an existing link. We have that now and can work out how to use it.

Pair-programming with the client again. That same fear of "this is never going to come together". But it did before, and we're already halfway through the biz rules for this iteration.

Planning meeting yesterday for our second iteration. Results largely as expected: more business rules, more documents. Plus driving a 'spike' for the mainframe interface to demonstrate that we can link all the way through.

We have our nominated mainframe programmer! And at the main customer site! We'll have our first conversation today.

Feedback from the users from our 'releases' is useful and keep us on track; but nothing like as useful as feedback from a production system. How soon after getting a mainframe link running can we get something into production?

Back yesterday afternoon to reviewing test cases with Sarah, one of the trainers. Good to be back in close communication again.

I notice the reported XP effect. Work is faster and more intense in close communication. Last week worked again one day at Joe's home in the Hampshire countryside, then the following 2 days co-ordinating by phone and email: hardder to maintain the intensity and momentum without co-location.

What we did last week. Back after the Easter break, but without our On-Site Customers -- school holidays still going.

Our mainframe link project has shown up, and I look like winning the sweepstake we set up for the date work starts! (One for the optimists.)

Joe and I were able to use the time to rework the exchange of data between the mainframe link I've faked and the SVQ editor.

Refactoring has left the code organisation looking less like the worksheets. I regret this and am vaguely uneasy about it, but the logic for it seems compelling, driven by what values the users might edit. Might have a 'refactoring insight' about this later.

Still having to fight for YAGNI. The habit of coding what 'we're going to need later' is still strong. It's not our money to spend like this.