Category Archives: Process

Mechanical Turk?

I went into a Barclay’s Bank last week. My wife asked me to pay some money into her account.

I know she normally insists on dealing with counter clerks and shuns the various machines they have in the foyer for paying in, paying out, getting statements, etc.

I thought I might try the machines, but was swooped on by one of these ‘Eagles’ Barclays have to get technophobes to start using the technology. This was a rather young eagle, and possibly more an eaglet because she told me more than I think she should.

We went through filling in a paying in slip (how quaint) and putting the money and the slip into an envelope. I was given the couterfoil for the paying in slip and then the envelope was placed into a slot in the paying in machine.

Then the Eaglet said; “And now Stuart will process that payment”. Stuart? Is that the name of the machine.

No, Stuart is the person sitting at a desk right behind the slot. It wasn’t a machine. It’s a mechanical letter box.

So, after the Eaglet filled in the paying-in slip, Stuart then handles the money again, counts it again, verifies the paying in slip and then enters the data into the bank system.

And they want to teach people how to use technology?

Surely Barclays, you need to reduce the human processes, not increase them? My wife thought it laughable. If she’d walked into the bank and deposited the money with a counter person, the data would have been entered into the computer system by a single person.

Or does it actually print it out somewhere and a clerk with a quill pen update your own ledger with the transaction?


YAGNI applies to process

You Ain’t Gonna Need It – YAGNI, comes from extreme programming. Basically don’t write code just because you think you’ll need it.

YAGNI also applies to documents. In the Scrum control methodology the main concern is Return on Investment (ROI) for the customer. And this applies to non-software items.

You should always ask; does the customer want or need to pay for this?

In fact you can probably not create quite a lot of documents. Process documents for example. If you come from a traditional (waterfall) project management background or even if you think you are agile you may want to create a document that ‘captures’ best practice.

Don’t do it. Scrum has a retrospective activity that allows the team to consider how to improve what they did.

Good practices should be like folk lore; passed down by experience and demonstration.

The oral tradition applies to management. Any document should have emblazoned on the front:

‘Out of date if you are reading this’.