Mike Roberts points out the difficulty of applying Agile methods in an organization with values that don't match those of Agile practioners. Specifically Mike describes the difficulty (but possibility) of using an Agile method when the organization doesn't align software development with business value. Why business value? Well, according to Mike this is what many feel Agile methods value:

The principles behind the Agile Manifesto state "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." I've often heard this shortened into a frequently used battle-cry of Agile: It's all about business value!.

("Business Value" here seems to mean some objective, measurable bottom-line goal)

Mike then goes on to note that in an environment where this "Business Value" is not the goal, Applying an Agile method successfully is much more difficult. Fortunately Mike also points to a way forward: "what's needed is a knowledge about what motivates every individual within the stakeholder community." I assert that this is what should be done in the first place.

I think Mike has (perhaps unintentionally) illuminated a flaw in Agile as commonly practiced these days. Namely: those Agilists who are running around issuing the battle cry of "Its about business value" are making software development about them rather than their Customer. I.e. they are violating the very principle they profess to practice.

If you don't feel its important to understand what your customer values, if you assume that they (or worse tell them that they should) equate valuable software with 'software of Business Value' of course you are going to have a very difficult time succeeding (unless they happen to agree), because you are working toward a goal other than that of your Customer.

For those people who believe this (I am not saying that this necessarily includes Mike) what I am about to say might seem profound (to everyone else it'll just be common sense): Customer satisfaction is not achieved by preaching to your customer that they must strive for "business value" -- or any other valuation that you have defined as important, but rather by understanding their goals and giving them software that achieves what they value, whatever that might be. IOW: 'Business Value' means 'What the Customer Values' -- no more, no less.

So, save yourself the trouble; leave this "Business Value" stuff out of it. If that happens to be the goal of your Customer then by all means that's how to measure the value the software you're creating (and certainly its good when one has such customers), but that does not imply that it must be the goal of one's Customer, or that there are not legitimate Customers who may value something else (particularly in big IT where Agile adoption is all the rage right now). That little detail seems to have gotten lost during the Agile diaspora.

The fact that "[S]atisfy the customer through early and continuous delivery of valuable software" has turned into: "It's all about business value" means that being about the Customer, or more generally the People (once a key Agile value) is no longer true. If this is the case, this reinforces my feeling that Agile is in the process of becoming its opposite, serving to reinforce the very problem it was once a reaction against: Programmers deciding what's important for their Customers, instead of asking them. Wrapping it up in a pretty Agile wrapper just soils the wrapper.

In short, its not about whether one's stakeholders are striving for "Business Value" that makes using an Agile method hard, its that getting one's stakeholders aligned is hard -- regardless of method. What allows one to deliver anyway is the ability to align one's effort with the customer's desires, not the other way round.

Not telling them what they must value would be a good start.