“A demain!” – story about dealing with a sales-focused vendor

Have you worked with a service vendor which consistently did not meet dealines, yet you still kept buying services from them?

This is a story about a car manufacturers’ service organisation being geared towards sales – not service. I’m sharing it here because it has analogies to what’s happening in the software industry. So I hope you’ll stay with me:

My Renault Espace broke down on a vacation in France. It’s a great car, usually very reliable, but like anything else, it has its weak points. The gearbox is one of them: I’ve seen numerous reports on failing gearboxes. Mine did 277,000 km before failing. Not bad, considering…

I delivered the car to a large Renault operation in the city of Frejus on the Côte d’Azur. I was well received, there was even a girl speaking English. I felt comfortable, and got a chance to look at the new cars.

Repairing an automatic gearbox is a specialist task, but replacement gearboxes are available. I started looking at the various options for repair – and for getting the family home to Denmark before our vacation ended.

So I asked the manager at the garage two questions:

  • How much will a repair be?
  • When will the car be ready?

Now, I’ve done a bit of work on my cars over the years, and I know that unplanned things can happen, so I was happy that he gave me a conservative time estimate that would allow for delays in the process. I was most worried whether a new gearbox was in store somewhere in the Renault network, but there was one in Paris, so I accepted.

And with the replacement gearbox arriving from Paris just a few days later, I was happey. When I checked with the garage, they told me they’d start working the same day, and I could have the car two days later. That would be one day earlier than promised.

”Sounds good, we’re ahead of plan,” I thought, and since buffers are always good to have, and I felt I could accept the optimistic estimate. I still trusted them.

But I was in for a surprise when I called two days later to ask about pick up. The answer was ”a demain!” – tomorrow. Any problems?, I asked. No, no problems, they said, ”a demain”.

I went to see the car later the same day, and the picture here shows what found: Note that the old gearbox is still in the car. The mechanic had obviously not started working on my car the day they said he would do it.

IMG_8259-3-SMALL

”C’est possible,” they claimed next day when the mechanic was still busy reassembling the car. I didn’t trust that, as the car obviously needed more work than was available on that day only. A sound test drive, for example!

As I’m writing this, I’m waiting for my car, sitting next to the service counter, where cars are registered for repairs. There’s a large poster showing the people working in the garage – and then there are all the new cars here. I like the electric vehicles Renault is offering, and everyone here is smiling and polite, even the service people. I feel comfortable here.

Renault’s business model is 100% sales oriented: They want me to buy services, buy a new or newer car instead. They smile and tell me all sorts of apparantly good reasons why the repair was delayed – they have even apologized to my family.

But there’s one thing they haven’t told me yet: They prioritized someone else’s car over mine, and they didn’t start working on it until there was no slack in the plan anymore.

This could be an example of french ”laissez faire” attitude, but I don’t think so. I’m not at all worried about the quality of the repair itself, as I saw the mechanic several times while he was working on the car. I know how Renault train their mechanics, and it was obvious that he was doing a really proper job.

No, It’s the planning that sucks. they didn’t know when they’d be done, so they didn’t call me to let me know the plan was in jeopardy. They just hoped. Even today they said: ”Dix heures”, and it’s now 09:59.

The interesting thig is that this is supporting their sales! It’s obvious that Renault has tuned even their flawed, but kind service organisation towards new sales.

How is YOUR vendor tuned?

PS: I’ve got the car now, and it’s as great as ever. Ready for at least another 150,000 km!

Antifragility by Testing?

”There are two classes of things [] One class of things that gain from disorder, and one class of things that are harmed by disorder.”

Nassim Nicholas Taleb, author of the best seller ”Black Swan” is out with a new book: ”Antifragile: How to live in a world we don’t understand”. He gave a lecture at the London School of Economics on December 6th 2012 during his book tour. The lecture is available as a podcast here.

”Technology is inherently fragile.”

The words are Nassim Taleb’s , and the statement should not surprise any testers: Testers can find bugs in even the best pieces of computer software: It is only a question of having useful testing heuristics, how much effort we’re using, and about observation skills of course.

”In psychology, people talk about post traumatic disorder. But very few talk about post traumatic growth.”

I am a big fan of Nassim Taleb for his original philosophical thinking and his ability to think and speak clearly about subjects which are very complex and sometimes even counter intuitive.

Taleb has a lot to teach us in testing, and it is very obvious to me that fragility is something that we should start looking for.

”The difference between the cat and the washing machine […] is you need to fix [the washing machine] on every occasion. The organic self-heals.”

Computer systems do not self-heal – they are inherently fragile.

Photo of Nassim Nicolas Taleb giving a lecture
Nassim Nicholas Taleb (photo: Bloomberg)

But let’s step back for a moment, taking a broader look. Let’s look at the systems incorporating the computers and the software: Organizations using information technology to run their business, communities using IT to stay connected, factories with machinery, workers, managers and computers to run them. Can any of these systems be described as antifragile?

”You should never let an error go to waste.”

My question is ”Can testing be applied in such a way that it not only detects fragility, but instead facilitates the development of anti-fragility?”

I believe that the answer is yes. And yes; there are antifragile systems out there incorporating computers and IT.

Please consider a recent test activity you participated in. Now think about the system which was building the product you were testing (my apologies for using manufacturing terms here): The people, the project teams, the organization. Such a system is organized into layers, and while the bottom layer (where the technology is) is usually inherently fragile, some of the higher level layers were perhaps antifragile?

This is where I see the role of testing coming in:

”It’s not about trial and error – it’s about trial and small error.”

In this very statement, Nassim Taleb, in my humble opinion, speaks clearly about what testing is about. The antifragile system for developing products grow stronger when testers find problems, since not only will the system learn from experience; no the antifragile system will prepare itself for things that are worse than what was experienced.

Put in another way: The antifragile software project does not just fix the bugs it encounters. The antifragile software project fundamentally eliminates problems based on knowledge from the small problems testers find.

So my message to project and and program managers is this: Don’t hire testers to find the defects. You should hire great testers to ensure your projects experience many small problems, allowing them to grow stronger and build better products: If your project systems are anti-fragile by structure, leadership and management, not only will bugs found by testers not be found in production: The overall quality of the product will be better!

And that, to me, is where the real business value of testing is!

Thanks to Jesper L. Ottosen for very constructive reviewing and commenting of drafts of this blog post.