Agile Ontologies: Why the customer is always right, even when they're wrong

Craig Brown voiced a common concern project folks have in "A Downside of Agile Development?" on his Better Projects blog, writing about his fears for his company's proposed transition to Agile:

I use a few online services, and you can tell which ones have adopted the philosophy of incremental product roll-out.

Just about every time you log in, there is another feature being promoted and presented to you for consideration.  Sometimes things you were used to have moved or disappeared.

This constant change makes some products less appealing than something that is more reliable.

There are valuable lessons to be gleaned here about what Agile is failing to communicate to customers. I like to think that the customer is always right, even when they're wrong, and if they're having a problem, then there is a problem. Brown is making visible a world view problem that is hindering agile adoption.

I left a comment on Brown's blog trying to reframe the question. Here it is:

This seems more like a web design  problem than a development problem to me. A product can be designed from the outset so that you can add to it without disrupting the work flows users have established. A top level menu system whose categories are general enough that you can fit almost any new feature under them, for example, allows you to release new features iteratively and allow users to discover what they need as the need arises. The problem may lie in treating each new feature as a "release" by shifting features around and making big front page announcements ala "Now with extra cleaning power!!!!" Constant improvement is not a series of events, and every addition doesn't need to be celebrated. Most of the time, it's enough to blog the new feature and move on. This is better than saving up features and doing a faux release. Why would you make an innovative new process mimic an obsolete process? Better to adapt how you think about the product instead.

I think I only captured part of my thought process in the comment, so here's the rest of it:

The takeaway is that often the resistance to Agile, or any other new way of doing, working or living, springs from underlying assumptions that aren't being unearthed and challenged. These assumptions are not ignorant--they are unconscious, and based on experience. As change agents, it's our job to challenge and persuade, not the other way around. For a customer who has lived through Vista or iTunes 8, and maybe a buggy beta or two of their own product, announcing happily that Agile will allow you to release every week will justifiably cause panic and soulful dread. Better to say, "We can make it so you never do releases. We build and test constantly behind the scenes, and add new features without disrupting your users' workflow. You'll never have a beta or a bumpy release to contend with."

Paul Graham wrote years ago that "...designing Web-based software is like designing a city rather than a building: as well as buildings you need roads, street signs, utilities, police and fire departments, and plans for both growth and various kinds of disasters." This high-level re-imagining is what Brown really needs to hear--he needs the shining city upon the hill, and for the leap of faith we're asking him to make in joining the revolution, he ought to get it.

Someone in the audience at the Scrum Gathering keynote last week reminded us that "A good trainer can lead a horse to water, but can't make them drink. A great trainer can make them want to drink." It's not enough to offer the customer better solutions and value, we have to offer them a vision of a better world; we can't focus on delivering processes and tools; we must focus on individuals and interactions.

Comments

[kiteboardingkites]

Yup! This is a question that still keeps on bothering the "owner" LOL. For me, customers are always right although sometimes they are wrong because they think that if not because of them, a business will never prosper.