Thoughts On ...

January 17, 2006

Aligining Value

"The shaping of deeply felt values into meaningful, apposite form, is present in all communities, and will find some means of expressions among all..." -- Dell Hymes

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.

Posted by wcaputo at January 17, 2006 02:40 PM
Comments

Recently, I'm concerned about the belief that just asking the Customers what they want is the best way to come up with solutions. I don't think it's either "developers know best" or "customers know best" but more a collaboration between developers and customers.

The point I'm trying to make is that "Value" may be more than just what the Customer values.

Posted by: Jason Yip at January 18, 2006 03:16 AM

Collaboration is the best way to determine what software should be written, but that's not what this is about. This is about determining how to value what is written -- that is the customer's perogative. You may find buying a car a more rewarding experience if you cultivate a collaborative relationship with your sale's person, but its neither his -- nor the car designer's -- wants, needs and philosophical beliefs that must be satisfied by the purchase, its yours. We're in the same business -- we just design (and the compiler builds) the car while you're in the showroom.

Making "business value" an a-priori criteria for how to measure the progress of software development is neither endemic to Agile, nor the best way to determine success. Listening is.

So many people in our industry really seem to get off on waging campaigns; pushing their vision of what the world aught to look like. We are in the Customer Service business, we need to listen. Trying to make professional software development into a moral crusade is great for the ego of the programmer, but it really sucks for the guy who just wants to make sure that he meets his career goals this quarter. Asking what those are -- and how the software we are being asked to write helps with that goal -- preceeds both collaboration and determining how to measure success. Period.

Posted by: Bill at January 18, 2006 11:25 AM

One more thing: Collaboration is also best for determining "how" to achieve those goals -- I have a vested interest in the quality of my work, the environment I work in, and estimates I provide. I can neither have that dictated to me, nor dictate these to the customer. We must reach agreement.

But again, I think that this is distinct from the principle Mike cites, and other have turned into "It's all about Business Value."

Posted by: Bill at January 18, 2006 11:29 AM

You need to align the following 3 things:

1) How agile improves profitability.

2) How agile improves the customer's life.

3) How agile improves your life.

If you work for a different company to your customer, you need to ensure add a 4th factor for your company's profitability.

Ideally, improving one should improve another.

If improving one has an adverse effect on another factor, then this should be understood and company and reward structures need to be changed to try and reduce the risk of this causing a problem.

Posted by: Richard Jonas at January 19, 2006 08:13 AM

Thanks Richard,

I think that's a good summary. I certainly found that I needed to consider #4 when consulting. And all of the other three ultimately must be satisfied by any project (especially #2 & #3), that I would call successful.

However, where I think a lot of people (i.e. the straw-men I've asked to hold the view alluded to in the main entry) -- particularly when they attempt to introduce agile to a large organization -- get into trouble is that they don't see the (often) large gap between 1 & 2 when their customer (i.e. the one hiring them) is distant from those who drive the business. In such cases, we can't simply shout "business value" (#1) because those parameters are already set (generally by someone else, long before we show up), nor can we simply go grab the person who set those parameters and make them customer, instead we have to understand how that goal has been translated into *our* customer's goal (i.e #2) and work toward that. If we can't demonstrate how Agile will do that better than the alternative, we will meet a lot of resistance. It gets even worse when there are *several* such stakeholders (including an architect's group in the mix is one common one) because they may have very different (even conflicting) goals that have been derived from the pure "business value" goals of the organization. Succeeding in such environments is hard, but no more so for Agile than others -- unless one cling's to the notion that "doing Agile" means "nust measure software value in terms of business value" and then -- as Mike alludes -- it is nearly impossible to get such organization's to adopt it.

My contention is that this phenomena (Agile As Battle Cry) comes from an inappropriate, dogmatic interpretation of Agile, by those who just want to keep doing/selling what they always did, but are wrapping themsevles up in the buzz phrase of the day, and/or by those who look for formulaic solutions to managing software.

Both groups are turning Agile into what it once purported to be trying to change. C'est la vie.

Posted by: bill at January 19, 2006 09:59 AM