Another Xp Experiment
Another Xp ExperimentThe company I work for has just hired out a bunch of us to build some distributed components. There are a dozen or so people involved: my colleagues, domain/technical experts from the client, and some contractors.
There's a sizable body of code existing, and a mountain of text and pictures: dozens of huge, intricate usecases; many vast, I mean vast--6 pages of A4--UML diagrams in Rose (colour-coded and with all the lines at 90 or 45 degrees, very pretty). Most of this was produced by a previous team from one of the UK's largest and longest established IT shops. It took them months. It sucks. They got sacked. We have the original timescales to meet.
What with one thing and another I'm nominal leader of a team of 4 working on the "security" (user profile, really) component.
Now, even though the previous team's full on RationalUnifiedProcess project went down in flames the client (a very trad. City of London firm) is still completely sold on by-the-book RUP. They have the wall charts to prove it.
But, we need to get the job done, so I've been trying to sneak some XP practices in; partly in the hope that this will increase our chances of success, partly to give me a chance to stress-test these ideas.
PlanningGame: something like it is going on inside the team. There is some overhead in coming up with plausible mappings from the tasks we are actually doing, that we worked out that we need to do next and can do in a week or so, and what appears on the PM's HolyGanttChart?.
The team are hooked on JUnit, and are beginning to see the benefit of writing the tests first. None of us (me included) are really doing this completely consistently yet, but we're getting there. One minor triumph, the PM was convinced to take the "Unit Test" task off the end of the phase and roll that effort into the other tasks.
We've managed to keep the domain experts handy, and whenever they aren't being forced to churn out more documents that no-one will read we take them into a room with no phone and say: imagine we have just logged into a terminal, and we want to...
We talk to each other and look at each other's code a lot. Client feedback so far suggests that this has been noted, deemed to be a good thing, but has come as quite a surprise to them. PairProgramming I've not broached, as the PM is very touchy on the subject of resource and I just don't need the hassle at this time. Maybe in phase 2.
Some of the team are not too comfortable with spike/do the simplest thing/refactor, they feel it is a waste of time when they could "get it right first time". I've been trying to explain that it takes time, but the time is not wasted. and you can't get it right first time any way.
Cards: well, no. Someone picked them up allright, but he wasn't hooked. He was scornful and dismissive. We'll maybe try again sometime.
We have negotiated a weeks reversing into Rose after we deliver, avoiding the need to maintain all these huge diagrams as we go. The client has expressed some concern that not doing the pictures first will compromise the "quality" of the product. I think they bought the test and continuous review argument, but it may be that the tight schedule has lead them to accept a level of "pragmatism" (i.e. slipshod working, as they see it) that they would not otherwise. Later phases have much looser time constraints, we shall see.
We are going fast. One of the team expressed a worry that we will "do our selves out of a job".
Keith, you might find some benefit in adapting the ExtremeUnifiedProcess docs. Is it RUP? Sure it is! Is it XP? You betcha! It's MSF too. It's a mouthwash, a floorwax, and it'll cut kitchen chores in half! --PeterMerel
But: will it make me tea and toast in the morning?
Well, we delivered "Iteration 1" to the application teams, who seem pleased. The client it very pleased, as this work had a reputation for impossibility. We were, by one measure, three days a head of schedule. All our "quality" sign-offs have gone through.
Of course, all these statements are equally true of the other teams on the project who were doing something very much more like by the book RUP (with some of the sharpest corners cut off it), so that's fairly inconclusive. Our (pseudo XP team) was noticeably more relaxed throughout, however: working hard but not long hours--except for a couple of days after our far too late integration with the other teams (for reasons outside our control).
So, thus far the jury is still out.
I have been discussing some XP ideas with the project manager (he hated the name immediately, by the way), and he seems open to them. I will test this in iteration 2, when I refuse to put any tasks on the six/eight-week look-ahead Gantt chart more detailed than "Deliver Component", and start gathering user stories, even though we already have some documents with "Use Case" in their title.
OK,
The Client liked the fact that iteration 1 came in on time, and to spec., but there was a lot of flack about doing that again for iteration 2, but doing it "properly" this time. The project manager has faith, however (he's easliy pleasd by results), so that has pretty much gone by the board.
Still some resistance from some developers on test-before-code: partly because some of them don't like being told what to do, and partly because some of them have got "years of experience" of doing code-then-test and it "always came out all right in the end." When quizzed on how they felt about that style of working, the response was: "I expect to be pissed off." And partly because some of them would rather hack their way out of a problem than not have the problem occur in the first place.
Also, our pair programming experiment collapsed within days.
PlanningGame: no dice. Gantt, Gantt, and Gantt again. In particular, the PM won't wear any kind of LoadFactor or PerfectDays? argument. All estimates must be in "real" days. This is partly driven by client, who regards work done outside of a written-down plan for the whole project(task times person time date) as out-of-control madness.
Congratulations! So far so good. Remember BairsLaw.
No more would I say "RationalUnifiedProcess". I'd talk in terms of the other guy's interests, which probably have something to do with getting done. Names aren't important, delivery is.
In this environment (not an unusual one, in my industry), there are many, many groups within the client who will, without question, stop this project delivering (or even impose the penalties as for non delivery on my company even if we do deliver) if the boxes have not been ticked. And in the right order. Delivery is way down the list.
Good stuff, keep trying! --RonJeffries
Thanks. BTW, Ron, what actually do you do for a job? I mean, besides responding to any XP related postings here within minutes ;-) It's 20:40 BST here, so this is R+R for me (sad, I know), how do you get away with it?
I'm an independent consultant. Want me to come visit your project --rj?
Hmmmmmm, they think I'm a dangerous, unhinged radical with a disgraceful and unprofessional dis-regard for "Industry Best Practice" (c) Rational Corp.
I fear they would stone you to death and burn the building down around your battered corpse.
It rarely happens, but if it did, you'd then be seen as quite rational. Think good cop, bad cop. --rj
Don't know if this advice helps you, but here goes. Trygve told me of this great architect he used to build the house. Architect came over and Trygve and wife said, want this what that. Architect returned with new drawings and Trygve said, but we asked for a ixoflaxo indent in the ceiling, where is that? Architect, said, Ah, and wrote it down on his list of things to put in. Each trip, the architect had put in the ideas he agreed with, "forgotten" the things he didn't agree with. Eventually, if Trygve insisted, he put it in, otherwise, he left it out. He never disagreed with Trygve, only was very slow to do it if he disagreed with the idea.
Perhaps a similar approach can work for you.
''doesn't that rely on the customer not also keeping a list of what they asked for (as some of the pesky blighters insist on doing)?
BTW, I don't see why you have to broadcast ideal working days to your PM. If he can't do the math, do it for him, and tell him the answer in real days, just track the LoadFactor yourself. Does it matter who does the multiplication?
Apparently it did: when I tried to submit real days estimates they were immediately challanged as unrealistically high. Foolishly, I then exposed the reasoning behind them, whereup the load factor was recast as "risk" and "contingency" and the perfect days went into the plan.
Anyway: that project is now ended. The client eventually did absolutely the right thing and reduced scope! We were astounded. After wrapping up a few loose ends and preparing a list of to-dos for whomever picks up this work later we were out the door with smiles, handshakes and free drinks all round.
The dust has settled, and a few conclusions present themselves:
Thanks to whomever tidied this up, I had difficulty connecting to save the changes, then was called away before I could review the results. KB
EditText of this page
(last edited May 21, 2004)
or FindPage with title or text search