“Nice to see taking on customer experience as part of Definition of Done outside UX community.” (Aviva Rosenstein: @uxresearch)

“Shift from output to outcome' was a great thing I learned from @jeffpatton 2 years ago.” (Joel Tosi: @joeltosi). I would also like to salute the pioneering work of Jeff Patton, which is highlighted in my book.

A defense of the Agile Manifesto

Nevertheless, one reader (Kevin Ross) posted a long and passionate defense of the Manifesto here on Forbes, which deserves a thoughtful reply. He answered my article point by point, and I will reply to his reply, point by point.

1. The need for a shift from an output (working software) to an outcome(delighted clients)

Kevin writes: "Delivery of a user story" is the measurement of output, and you argue that the outcome should be to delight the customer. If the customer defines the user story … then the customer should be delighted with the result…For this reason, I don't think any update is necessary to the language of the manifesto.

My reply: Doing what is contractually agreed is a condition of staying in business. In 2001, most software development wasn’t accomplishing even that and so introduction of the Agile practices that enabled completion of contracts on time was a welcome advance.

In 2011, almost everyone is delivering what was agreed on time, but that’s not enough. To flourish in today’s more competitive business world, you not only have to satisfy the customer by delivering what was agreed on time: you need do more: either deliver more value than agreed or deliver it sooner. This turns the customer from a business partner into a loyal fan who will want to go on doing business with you and publicize your work to others. In 2001, “working software delivered on time” was enough. In 2011, it’s not. That’s why the language of the Manifesto needs updating.

2. The need for a shift from customer satisfaction to customer delight

Kevin Ross: All parties in agile are intended to communicate about the same thing in the unambiguous business language defined by the customer. How can a developer know what delights the customer if they did not define it as a story or acceptance test? If you are simply leaving this to the developer, how would you ensure they aren't working on something to "delight" the customer that actually isn't valuable in the customer's eyes and doesn't deliver value as defined by that customer? This is the very definition of waste or muda.

My reply: Delighting the customer is a complex task to which everyone in the organization should be expected to contribute, including the developers. Obviously the minimal responsibility for developers is to complete in each sprint what was agreed on time. The push to enhance value should not distract them from this basic requirement. But while they are accomplishing the basic requirement, they should also be thinking: is there a way to deliver value to customers sooner? Is there a way to deliver more value? For instance, at Toyota [TM], employees make around a million suggestions for improvement each year; not all of them are implemented, but the shared responsibility is evident. Equally important as encouraging employees to come up with improvements is doing experiments to check out whether they do actually improve things—something that Taiichi Ohno emphasized at Toyota. And we should keep steadily in mind Eric Ries’s dictum that most changes make products worse. Matt May's excellent book, The Elegant Solution: Toyota's Formula for Mastering Innovation (2010) is useful reading on these issues.

3. Shift from an implicit goal to an explicit goal:

Kevin writes: I would argue that this is most important and a precursor to the entire process. No effort, regardless of discipline, couldn't benefit from establishing the goal. For this reason, every new employee at Metova receives a copy of The Goal by Goldratt on their first day. Goldratt's Theory of Constraints (TOC) is fundamental, and perhaps could be seen as the foundation of agile, and anyone knowing and practicing the TOC will become a dramatically better implementer of the Agile Manifesto.

My reply: I am glad that we agree on making the goal explicit. And I agree that Eliyahu Goldratt’s book, The Goal , is a wonderful book to read if you are trying to run a factory and your only concern is how to get the factory to deliver its outputs on time. Written in 1984, the book did for factories what the Manifesto later on did for software development.

But the book is at best an incomplete guide to running a business. In The Goal, the customers hardly figure: there is little discussion of what the factory is producing or whether anyone is likely to buy it, or what their reaction was when they did buy it. Yet those questions are central to the eventual success of the business. I would therefore suggest that in addition to providing your employees with Goldratt’s marvelous book, you might consider also giving them a copy of Ranjay Gulati’s book, Reorganize for Resilience, which explains in detail why the inside-out mindset that is prevalent in The Goal needs to be replaced in 2011 by an outside-in customer-oriented mindset.

4. Customer delight is a new dimension of “done” in Scrum:

Kevin writes: "Done" is something that should happen everyday. Cadence is important, delivery is important. Developer satisfaction stems from delivering and customer satisfaction and confidence stems from receiving such a delivery. Any attempt to define "done" as "customer delight" might simply be too much for a developer to feel is achievable…

My reply: The idea that developers are incapable of making any useful suggestions as to how the firm might deliver more value to customers or deliver it sooner is not an assumption I can accept. Any organization that starts from that assumption will be underperforming on its potential, as well as dispiriting the talent that it has.

Kevin writes: This sounds much more like a symptom than a root cause, and any attempt to address it would be of "contingent" value. 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.

My reply: Figuring out what will delight a customer is a difficult, complex task to which there are no easy answers. It’s a process of trial and error, with many iterations. The nomination of a product owner to speak with one voice to the development team as to what the team should work on is a huge improvement on having many voices give the team inconsistent instructions. But even the greatest product owners like Steve Jobs at Apple [AAPL] make errors.

Thus in the late 1970s, the Apple II had been a best seller for the home market. The Apple III was the firm’s first foray into the commercial market. As features grew, the machine’s chassis became increasingly crowded. Steve Jobs insisted, as he had done with the Apple II that the Apple III not contain a fan to dissipate the heat generated from its densely packed components. Jobs considered the noise of a fan to be industrial and inelegant. When volume shipments began in earnest in March 1981, approximately 20 percent of all Apple IIIs were dead on arrival because chips fell out of sockets during shipment. As a result, Apple III failed in the marketplace.

The point is that giving clear directions is important, but if the directions drive the company into an iceberg that doesn’t help the firm to survive. The clear directions need to be accompanied by continuous experimentation to ground-truth them: do they reflect what customers really want?

6. Customer delight is the bottom line for the whole organization

Kevin writes: Agreed, it's about the goal, but this should be a precursor and the #1 priority before undertaking any effort. Understanding company goals is critical to then define software that delivers value with respect to that goal.

My reply: Great!

7. Customer delight is measured. e.g. Net Promoter Score

Kevin writes: It's simpler than that. I agree that measurement is absolutely essential, but measurement in Agile is the pass/fail language of an Acceptance Test that supports a story. If the software is still not exactly what the customer wants, iterate.

My reply: “Customer acceptance” is different from “customer delight”. Acceptance means that customers don’t return what is delivered. Delight comes from getting more than expected.

Thus I might have “accepted” Microsoft [MSFT] Office 2010, in the sense that I haven’t returned it, but I am far from delighted, given issues with the 2003 and 2007 versions that are still unresolved and given the many changes that make things worse for (e.g. two clicks to do what used to take one click). I am a typical example of a disgruntled customer who is ready to jump ship the moment a suitable alternative emerges. Relying on the Pass/Fail test of customer acceptance is a very misleading indicator of how loyal your customer base is. To get a more accurate assessment, you need to be using something like the Net Promoter Score to determine the future of your business: are your customers delighted?