The 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.
: 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!
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.
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.
: no dice. Gantt, Gantt, and Gantt again. In particular, the PM won't wear any kind of LoadFactor
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:
- We tried to use PP to achieve knowledge sharing between client staff and our people, and also to bring a less experienced person up to speed: failure. For much of the project people were, whilst not formally in pairs, generally working together, although usually with a machine each. It was noticeable that the "LoneWolves" generated more defects, and were less likely to hit their estimates than the pseudo pairs. I'm not yet compelled that the pairing was the key factor here, however.
- A roaring success. The PM was completely won over, and has included this approach to testing in a proposal. Even better, there are now quite a few TestInfected developers, both with the client and my own company, spreading contagion!
- FearOfChange, fear of incomplete specs/designs, FearOfUncertainty?. Some of our developers just could not overcome their fear, even given a good deal of support. It seems like not knowing exactly what to do next will *just stop* some people.
- Ultimately, delivery is the best response to criticism.
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