Steve Denning suggests the Agile Manifesto needs to be updated, to reflect the fact that working software, its primary measure of success, is no longer good enough — customer delight, he says,  is the new benchmark for success. In doing so he has drawn criticism saying that customer delight is a worthy, but ultimately pointless aim for developers. In this post I want to show that the debate isn’t helpful: we need to separate principles of software development from principles of creating great products to avoid putting people in conflict.

Calling for an update

Steve’s starting point is this:

In 2011, “working software” is not enough. Unless the customer is delighted by the working software, the future of the business is not bright. Customer delight has become the new bottom line of business. Firms that succeed in delighting their customers like Amazon [AMZN], Apple [AAPL] and Salesforce.com [CRM] enjoy happy customers, soaring profits and workers who can see meaning in their work. Firms that don’t experience the opposite.

His solution is then that “customer delight” should be embedded into the agile process — and in particular into the Agile Manifesto. It’s pretty hard to disagree with many of Steve’s broader points: that goals need to be embedded deeply in an organisation to last, that product development is only really “done” when the customer’s happy, that customer happiness can be measured, and more.

But is the Agile Manifesto the right place to embed the goal of customer delight? For one thing, his exemplar companies demonstrate nothing about agile methodology. Amazon, Apple and Salesforce.com delight customers with their customer service, their hardware, and their ubiquity respectively. They may use agile development techniques, but their USP and their market cap (Steve’s indicator of excellence) is not an extension of the Agile Manifesto. Similarly you’ve got to have a pretty peculiar view of the world to think that Walmart, Cisco and GE (Steve’s examples of companies which aren’t performing) would shift to a stellar performance if only the Agile Manifesto could be updated.

Antagonising developers

Because Steve seeks to rewrite specific agile practices, Kevin Ross and Nathan Gloyn get stuck into those details and show why he’s mistaken. And yet aside from the specifics there is a common underlying feeling expressed by both Kevin and Nathan, which is that developers have a hard enough time as it is, thank you very much, and they can only do their job effectively by trusting that their colleagues (the product owner, the company board, etc) are also doing theirs effectively.

To that end, here’s Nathan:

I have multiple customers to satisfy ranging from immediate and upper management through external clients to actual users of the software/website who may (or may not) be customers of the business […] The PO is ultimately responsible for prioritizing/ordering the work to be done by the team and deciding what is of the most value to the business in helping delight customers but it’s a collaborative process that should involve the whole team and where appropriate also include the customer, but somebody does have to make a decision and that responsibility lies with the PO or PO team

And here’s Kevin:

If the customer defines the user story, as this is a significant requirement to deliver accurate software using most agile incarnations, then it should be a given that the customer should be delighted with the result. If not, this is a symptom, and the cause should be addressed. […] How can a developer know what delights the customer if they did not define it as a story or acceptance test? […] We rely on a product owner, and they make decisions, define stories, and define priorities. If your “product owner” can’t do that, you have to address it directly not try to work around it. We all have a role, and you have to depend on them to fulfill their role.

Reading the debate further it’s clear that all parties agree that delighted customers is the ideal end goal, so why the strong disagreement? By poking at the Agile Manifesto Steve has brought out the worst in Kevin and Nathan and it would seem, most of the audience of Agile Alliance 2011. Here is a bunch of educated, engaged developers who seem to be saying “Delighted customers? More than my job’s worth, mate.” Clearly this discussion is going awry.

Software development is only part of the chain

The source of the problem is that software development is only one link in the product chain: The pipeline of work coming into the development team has to run smoothly; the items going into the pipeline have to be the right things (e.g. things that will delight the customer); the end product has to be marketed well (would Apple have such legions of fans without great marketing?); customer feedback has to be balanced with product or company vision; and so we go round again.

That one link — software development — is so difficult, and has such a history of problems, that the practitioners had to produce a manifesto to point the way forward and keep them on track. When you start poking at the island of salvation that is the Agile Manifesto the practioners are going to get jumpy. The manifesto is of specific interest to software developers, so trying to add in “customer delight” looks like it is giving that responsibility to the developers while ignoring product managers, CEOs and marketing execs who feature more heavily in the other links in the chain. No wonder the developers are going to say “Hey, what about those other guys?”

No doubt we should all raise our game when it comes to product delivery. This might be achieved by dismantling that chain and bringing everyone together to think more effectively about the customer. Or it might be achieved by encouraging all team members to continually check and verify the current thinking, just to make sure everyone is focused. But it is not achieved by taking a philosophy of software development and turning it into a methodology for successful business.

Software developers need principles for effective software development. They may also utilise principles for creating a great business though great products, and perhaps those principles could be produced by adapting the Agile Manifesto. If so, such product development principles should be meaningful to everyone in the product chain. But principles for software development would still be necessary, and they would be different from principles of product development. They would be applied at different moments, for different purposes. They shouldn’t be confused.