customer

Guess who? (Kill the Agile Buddha)

  • Tuesday, 25 January, 2011
  • By:

Guess who am I now.

I’m in a supermarket, I’m pushing a trolley. I’m putting items into it. I just need some bread and I’ll be going to the checkout. Who am I?
I’m in a bank, queueing up in front a machine for depositing cheques. I’ve got a couple of cheques I need to pay in. Who am I?
I’m in an electronics store. I want a new printer but I’m not sure what’s the best for me, I’m looking for someone to help me. Who am I?

Or maybe what am I?

I am a customer.

Aren’t I?

Business language backs up my assumption. The employee at the supermarket checkout is called a Customer Service Rep, my personal (customer) details are held in the banks Customer Relationship Management system, in the electronics store I’m looking for Customer Support. And after I’ve bought my printer I’ll be asked to complete a Customer Satisfaction Survey.

So everything indicates that I am a customer. Or that is what I thought I was.

Apparently not according to the Scrum zealots.

At Agile 2009 Tom Illmensee presented a paper “5 Users Every Friday: A Case Study in Applied Research”. It describes how an eCommerce division of an electronics retailers introduced agile and how the user experience team adapted to agile. It starts by describing how their initial forays into agile were deemed successful. It was collaborative with the disciplines well integrated; “whiteboard wireframes, minimal documentation, and product demos. Usability tests with paper and semi- functional prototypes were conducted with shoppers each sprint”. More than that, the whole team enjoyed the experience. A decision was made to “take agile to the next level”. The next level was the introduction of a consulting firm who brought in scrum training. The scrum dogma was painful to adopt, but they got there in the end. But there’s a line in the paper that made me angry:

“The peculiar semantics of Scrum were especially confusing at first. In retail customers were people who bought things like stereos and flat-screen TVs. Not anymore. Agile had changed the definition of perhaps the most important word in our business environment: customers were now internal product owners. Customers would now be referred to as shoppers—or users.”

I’ll write that again. Customers (the people who the business depended upon, and “the most important word in [their] business environment”) would now be called shoppers. Or users. Because in agile, customers are internal product owners.

Sorry, these consultants, these agile zealots, these software egos have got too big for their boots. Dan North, pulling to pieces the nonsense of ‘software craftsmanship’ put’s it eloquently:

Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.

Software at the centre rather than the benefit the software is supposed to deliver. Software is the means to an end, not the end itself. If a certified scrum master (certified master based on two days training and a multiple choice questionnaire, now there’s a farce) tries to rewrite your business language, tries to tell you that your domain language is wrong, show him or her the door.

There’s a budhist saying “If you see the Buddha on the road, kill him“.

If you see agile in your workplace, kill it.

Why kill the Buddha? because the Buddha becomes an object, your own illusion of what it is. And it this illusion is wrong.  To turn the Buddha into a religious fetish is to miss the essence of what he taught. Killing the Buddha means taking responsibility for yourself.  Same with Agile; to turn agile, to turn software development into a religious fetish is to miss the point of what it is all about.

===

I presented on the customer theme a while ago, here are the slides.

And here’s me narating the slides on google video.

Does this train go to Bangor?

  • Tuesday, 2 June, 2009
  • By:

Over the loudspeaker comes a garbled message “…this train divides at Chester.  Customers for Bangor must travel in the front four coaches of the train”.
There was a group of women behind me talking loudly, one of them picked out part of the message and was worried.  The train guard (sorry, Customer Revenue Protection Officer) walked by.
One of the women got his attention, “Excuse me, we’re going to Bangor?” she said.
“Oh” said the guard.  “You need to get out at Milton Keynes and walk to the front of the train”.
“What? We need to change trains?” the woman replied.
“No, it is the same train, just the front part of it.”
“Is it on the same platform?” Asked the woman.
“Yes, just walk up a little” replied the guard.
“We don’t need to cross over to another platform then?”
“No, it is the same platform, the same train”
“So why can’t we stay on this train then”
“Because this part of the train divides at Chester?”
“But we’re not going to Chester, we’re going to Bangor”
The guard was getting frustrated, “when the train stops at the next station, you just need to get out and walk up the platform, in fact to the next carraige and get on the train there”
“So why can’t we walk through the train to the next carraige?”
“Because it is a different train”
“but this train is going to Bangor isn’t it?  We are on the right train aren’t we?”

And so on until a fellow passenger jumped in “when we get to Milton Keynes, I’ll show you where to go” and at Milton Keynes he led them all off the train to walk past the train divide on the platform and I’ll assume they made it to Bangor in one peice.

The point of this narative is that not everybody “gets it”.  Just because you think something is straight forward or obvious doesn’t mean that your customers will.  You are not your customer, be wary of making assumptions on how people will use your Great New Product.

Customer or Client?

  • Monday, 10 November, 2008
  • By:

One of the things that bugs me in IT development is that the business is too often referred to as “the customer”.  “Customer” implies a transactional relationship.  A customer purchases from a seller; there is little incentive for any meaningful relationship as it will ultimately come down to price.  The buyer wants to pay as little as possible, the seller wants to charge as much as possible.

All to often IT is seen as a cost centre rather than a driver of business innovation and profit.  Maintaining the transactional language to describe the relationship between IT and the business helps perpetuate this.  We need to stop thinking of the Business as our customer.  Instead of “customer” we should look to other professional services for our metaphor.

Professions that involve a more personal, relationship driven approach to their business use “client” rather than “customer”.  Whilst retail banking has customers, wealth management talks about clients.  I think it is a subtle but important difference.   The relationship between IT and the business should not be seen as transactional, it is more consultative in its approach.  Structuring our relationship as consultant-client is a small but important first step to redressing the perception of IT as a commodity.