February 20, 2010

...Learn TDD with Codemanship

When Does "Delivered" Not Mean Delivered?

On occasion, I take a calculated risk and buy something off eBay. Ninety nine times out of a hundred, I suppose, the sellers are on the level and ship my item as soon as my payment's cleared. Right now, I'm awaiting delivery of an item from the US, which I purchased about two weeks ago.

The seller shipped it by standard international parcel post and I've been able to track its progress via the USPS web site. Which is how I know it left the US on Feb 11th and arrived in the UK on Feb 17th. So far, so good.

But this is where things all go a bit Twilight Zone-ish. According to USPS tracking (which must now be gettings its data from Royal Mail tracking at our end), they "attempted" to deliver it at 11.20pm last night.

Uhuh? Are we doing parcel deliveries after the pubs shut now? I believe not. "Attempted" delivery I understand to mean that they stuck it in a delivery van and the van came to my house and the driver knocked on my door and there was no answer. Or they couldn't find the house. Or something like that. Basically, they tried to deliver it, but were unable to for some reason.

I was most definitely at home at 11.20pm last night, and wide awake, and sober, and would most definitely have noticed if someone had knocked on my door at that unsociable hour.

This is not the first time that an overdue parcel delivery has been tracked as "delivered" or "attempted delivery" via our esteemed postal service - the oldest (and now, it seems, the creakiest) in the world. I orderd a box of expensive cigars a few months back and it disappeared into their system for several days, while all the time showing as "delivered" on their tracking web site.

It eventually turned up, of course. And I pointedly asked the nice lady who delivered it why it was down on their system as "delivered" when it quite obviously hadn't been up until then. And she admitted, with little hint of embarassment, that this happens all the time and is done to keep their performance statistics looking good.

This is a growing malaise in British life. Targets and measures are routinely gamed by put-upon workers who frankly are given no reason to give a shit. Actually delivering the parcel is less important than being seen to have delivered it on paper. The management perception of performance and reliability weighs most heavily on the worker's shoulders - far more so than the customer's perception of the quality of service they're getting. So much so, in fact, that when I've dared to complain to sloppy service providers, they've called me a liar because their database systems clearly show a rosier picture than the one I, a mere customer, have painted.

This is all very well and good, having a Saturday morning moan and all. But there's a salient point at the end of all this. I've seen countless teams - Agile and otherwise - game their delivery data in much the same way. When you give the people doing the delivery the power to decide if something has been "delivered" and when their management relies on this highly subjective picture to assess the reliability of releases (by which I mean, when we say it's been delivered, has it really been delivered), we get a similarly disparity between the customer's perception and our own.

Of course, the postal delivery system is supposed to have checks and balances to make it more objective. How could something be "delivered" without a signature? Well, obviously it can, somehow. Perhaps the signature isn't really required. Or maybe any signature will do.

The solution is to place full responsibility for deciding if something has been successfully delivered with the end customer. And to establish very clear criteria as to what constitutes successful delivery. As it turns out, requiring a signature is by no means fullproof. What would probably work better is if customers were given a secret number or password to enter into the courier's little handheld computer thingy - or a barcode to scan - or something that can only be obtained by making contact with the person for whom the letter or parcel is intended.

In software projects, we need something that is a clear and unequivocal indicator that "the ball is in the hole". Not near the hole. In the hole. And this must be something that only the person who raised that specific requirement can control. Developers must not be allowed to make changes to the criteria. Only the customer should have that power. And these criteria must be beyond any doubt. They cannot be vague or handwavy, because that makes them game-able.

Practitioners of acceptance test-driven development will have some idea of what I'm getting at here. But I've watched teams doctor the test scripts without informing their customers, just to make a failing test pass and to meet a deadline, resolving to fix the real problems after they have "successfully delivered".

This cannot be allowed. ATDD works best when only customers have this power. Test scripts should be locked down in the customer's version control system, and nobody who touches the code should have the authority to check in new versions of the acceptance tests. If we want to move the goalposts, we must be forced to go to the customer and ask their permission.

Now, where's my bloody parcel?!



Posted 8 years, 5 months ago on February 20, 2010