Column 2

I was on the treadmill this morning with Malcolm Gladwell. Actually, he was on my iPod, and I was watching his talk from TED 2004, which was posted recently on the TEDTalks site (not sure if the timing is correct — although the website claims that this was recorded in February 2004, Gladwell mentions his book Blink, which wasn’t published until January 2005).

The topic of his talk was spaghetti sauce, and although the words “long tail” are never mentioned, the story that he tells is about, to some degree, the lengthening of the spaghetti sauce tail: how a single style of tomato sauce in the 70’s became the myriad styles that you find on your supermarket shelf today. This came about not by asking people what style of sauce that they wanted, since many had only ever been exposed to one type of sauce, but by offering them a huge variety of sauce styles and plotting the clusters of preferences, which turned out to be plain, spicy, and extra chunky. This in turn led to the explosion of styles of vinegars, mustards, coffees and many other food products, as the food industry learned a couple of valuable lessons:

Lesson #1: The way to find out what people want is not to ask them, since we can’t always explain what we want, especially if we are completely unaware of what alternatives are possible.

Lesson #2: Different styles of products are not better or worse, just different. This democratized what might previously have been considered a hierarchy of product styles.

Although Gladwell’s discussion about sauces convinced me that he has never had a “culturally authentic” Italian pasta sauce (my favourite is a pureed tomato and red pepper sauce that I learned to make at cooking school in Tuscany), he makes an excellent point about how the food industry was trying to treat us all the same, when we really wanted variability. As he summed up, “in embracing the diversity of human beings, we will find a sure way to true happiness.”

All that I could think of as I listened was that the lessons learned by the food industry could be well applied in software design (you knew that I’d be getting around to something relevant soon). One of the major causes of bad system implementations is to allow the users to design the system based on their current knowledge, through a misguided notion of what a JAD session is supposed to achieve. I’ve had this experience many times over when introducing new technology such as BPM into an enterprise: the business users have no idea what such technology can do, since they’ve never used it or probably even seen it before, so it’s foolish to expect that they are going to be able to tell you what they want the new system to do. Instead, they need to be presented with a vision of the future, or rather, several alternative visions, and be allowed to get their heads around what’s possible in the new world that includes that technology. I’m not suggesting that the technology should reshape the business process to fit its limitations, but that the business processes can radically change — for the better — with the advent of the technology, if they are allowed to do so.

The lesson about variability is a good one to take to heart as well. Many implementation “experts” have a set of templates that they seek to apply to every implementation in which they are involved; this maximizes their profitability since they don’t need to do much original design work for each project, but ultimately leads to unhappy users since it’s not so easy — or smart — to make one organization’s processes identical to another’s. The diversity of processes both within and across organizations is part of what makes an organization unique, and their ability to create that diversity easily while maintaining a common business goal is what makes for an agile company.