Falling From Grace

Nota Bene:

On this and some other pages I've been reflecting on the fact that the C3 team has drifted away from some of the XP practices and that we feel we screwed up and frankly feel pretty badly about it. Let me put that story into perspective here.

We were set up to load a huge population of new folks over the holidays, subject to a dry run on December 21. We didn't quite make it on the 21st but we pumped ourselves up to think that we could probably do it if we really pushed. We really pushed, finally got the thing up and running and didn't like the results, so we aborted the load. We felt bad, that we had let folks down, even though we did the right thing. We felt that we should have known earlier that it wasn't on, and that we sort of DID know it and didn't face up to it. So we feel dopey.

The customer, in view of this horrible "failure", has told us that they want to expand the scope of our project to cover more breadth as well as depth, doing some serious "business process re-engineering". More scope, more benefit. So keep that in mind: they're saying OK, cool, the launch didn't work, now let's do something more challenging and interesting. Our honesty, our focus on renewing our process, gives them the confidence to ride through a screw-up without even flinching.

So don't overreact to my concern here. We just went off process, detected it later than we'd have liked, regrouped, got back on. We didn't get our XP shirts taken away or anything serious like that.

My concern is, how do teams go off track, how can they quickly detect it, how can they get back on, all during stress? -- RonJeffries

Teams get off-track when an operational premise turns out to be false.

The C3 team, if you believe what you read here, is one of the most successful teams practicing XP over the long term. The most successful long-term team if you count only teams with XP shirts. (If you don't require shirts, you have to score Wyatt as first, most likely.)

The C3 team has gone off discipline three times that I can recall.

Refactoring Iteration

At one point, our load factor drifted from 2.0 to 3.0 We finally noticed, met, decided we hadn't been doing RefactorMercilessly, scheduled an extra Iteration for refactoring, did it, brought load factor back down.

Overtime to Release

In the first release, we had made a mistake in how far we pushed our testing, and got into a crunch against our planned deadline. Instead of just saying we had screwed up and publishing a new schedule (which is what you are supposed to do), we pulled something like six weeks of overtime. We finally got it out. When we stopped, we looked back and realized we had been less productive for the past four of those six weeks than if we had just worked normal hours.

Biweekly Load

We made a mistake in thinking we should load and cut over 15,000 people in one big bang. We were already behind where we had predicted we would be. Ignoring the little voices telling us that we couldn't possibly do this, and shouldn't even if we could, Customers and Developers pushed on until just a few days before the launch before whistling the play to a stop.

In response to this um, failure (which wasn't really that big a deal, but certainly was disappointing), I heard the following things before and during our revitalisation meeting:

A senior customer: We should assign specific pairs of programmers to specific stories, so there will be someone who knows what the story is, and whether it is done. (The customer is supposed to know what they want, and the TESTS tell you when it's done.)
A customer: You haven't given us the operational tools we need. (In spite of never having put any operational tools on the table at any IterationPlanning meeting.)
Someone, during a discussion about whether we could really meet the launch: We can't go back to Pat and tell him we aren't going to make it.
A very senior customer: Maybe you are paying too much attention to XP and not enough to payroll. (This at a time when we weren't testing enough, pairing enough, CRCing enough.)
A very senior customer: What do you mean, Overtime is bad? Overtime is a required part of doing payroll.
A developer: We weren't pairing because the choice was between working on your own stuff or helping someone else with theirs. (Huh??)
A developer: I knew we weren't going to make it but I didn't make anyone listen.
A developer: Maybe we weren't following the rules because we were trying to be too Extreme. (Huh??) Maybe he equated Extreme with Heroic -- DaveHarris

At the end of the meeting we were all on the same page again: we had gone off process, that damaged progress, confidence, communication. The core of what needed to be done was to get back on. Some new practices will be tried.

These were grown-up people who had been consciously doing XP for almost three years, gone off process and refusing to recognize it even when it stared them in the face, even when people had been saying explicitly, We need more tests, We need more CRC, We need more pairing.

What happened? What could avoid it? I'm still not sure. But I am sure that it has happened at least three times on the best living example of C3. XP is a HighDisciplineMethodology. And you have to maintain the discipline. -- RonJeffries

Your thoughts, questions, ideas will be helpful.

Sounds like the first deviation was just drift and the last two were overcommitment. Or am I wrong? Feeling pressured by the customer, or feeling a little gung-ho: "sure we can do this."

Seems like pressure, self-imposed or not, messes things up. However, it is human nature to add zest to things by seeking new challenges.

Another issue could be group-blind spots. Sure, it is the coaches' job to wield the RolledUpNewspaper, but with the ebb and flow of involvement it is easy to pay more attention to immediate issues than one's proximity to some standard. GeraldWeinberg talks about one of the benefits of being an outsider: it is easier to see what involved people do not see.

-- MichaelFeathers

I have noticed on other pages that some things I consider part of ExtremeProgramming have been removed. I know of 3 things. ExtremeProgrammingCodeReviews are one. Wearing one of two hats instead of OnlyWearOneOfFourHats. I had also heard a rumour that at CommitmentSchedule meetings each iteration is no longer assigned a theme. I would be very interested in hearing the C3 people saying more about what other practices have been dropped from XP. -- DonWells

See AdjustingExtremeProgramming.

CategoryExtremeProgramming