Today I read Jurgen Appelo’s “Value Is Customer Experience, Not Customer Expectation”. In his opening paragraph, I notice two key points¹:

Agility has helped software groups reduce cycle time in delivering new versions of software.
Value is experience, not expectation.

I agree confidently with the first of these and I quibble somewhat with the second. Nearly 15 years after first writing “Why I Try to Communicate in E-Prime”, my attention continues to rush immediately to any sentence centered on the word “is” so that I can ask the magic question “Is it, though?”

What Agility Seemed to Try to Do

I became interested in Extreme Programming because it seemed to represent a programmer-led revolution to achieve a few key goals:

practise the craft of programming more openly and with more care
gain a seat at the table when deciding what we would try to build in the first place
eliminate, once and for all, the Taylorist notions of programmers as fungible code-producing machines

I remember having a vision of software development projects as places where we openly negotiated what to build directly with the people whose lives we were affecting, then felt the freedom to build those things with all prudent care and attention. Efficiency would almost certainly follow, even though I viewed it as a pleasant side-effect of the rest.

What Went Well; What Needed Improving

Looking back at the past 20-25 years (as of early 2023), I notice two things:

I think we have made some substantial efficiency improvements, thanks to automated testing, continuous delivery, and shorter planning cycles.
We were at best naive about the complexities of figuring out what we should try to build in the first place.

I don’t mean the royal “we” here, but I mean that pronoun literally. I was naive and I apologize for all the gross oversimplifications that I passed off as good advice over the years. I’ve learned and changed my perspective.

I didn’t need decades of hindsight to understand this second observation. Not long after I first nailed “We’ll Try” to my IBM office door, I read The New Strategic Selling, which gave me a helpful introduction to the complexities² of both understanding and negotiating the concept of “value”. Even in the early XP days, we quickly began to discuss the differences between the “Gold Owner” (the “Sponsor” buyer) and the “Goal Donor” (some combination of the “User” and “Technical” buyers). We discovered early on that we didn’t understand value any more clearly than the next group of nascent thoughtleaders.

Of course, that didn’t stop us from having opinions! Neither did it stop us from telling you how wrong you were. I’m truly sorry about that.

You Fish On Your Side…

It didn’t take long for me to reach this conclusion about the role of Lightweight/Agile ways of working, such as evolutionary design, continuous delivery, and adaptive planning:

I don’t mean to say that I refuse to help you understand your needs better, but merely that as A Proud Lightweight, I recognize my role as adviser and guide, rather than as decision-maker. I don’t know what your strategy should be, so I offer to work with you in a way that provides two key benefits:

It does the day-to-day things well: information flows more freely, mistakes cost less time and money, value is realized more easily
It frees you up to decide what value means to you and your organization.

And this is where I quibble with Jurgen’s second point.

What Is Value? Mu.

I have no idea what value is, except an ongoing negotiation among various people at various times about meeting their needs. Maybe. That sounds pretty good, doesn’t it? It has a very philosophical ring to it. It sounds plausible. Even better: it sounds profound and trivial at the same time.³ So many great pearls of wisdom do that: they sound profound at first, then they sound trivial, and then 25 years later you bolt upright in bed in the middle of the night, suddenly struck by your appreciation for how very wise it seems. I can’t tell whether that’s a marketing trick or a fundamental irony about life.

Ultimately, however, I don’t think we can define value in a broadly-applicable way—not even in the relatively narrow context of delivering software in exchange for ready money. I don’t think we can and therefore I don’t think we should even try. Mu. Unask the question.

I encourage you to decide what value means to you as you build your company, manage your organization, explore the needs of your market, or whatever you do that involves trying to deliver software in exchange for ready money. Are you trying to transform a community? Are you trying to ease someone’s small-but-annoying pain? Are you trying to create a safe place? Are you trying to shake people out of their daydreams? Are you trying to give people something memorable? Are you trying to make something merely work without fuss all the time in the background?

I don’t know. You decide.

When Jurgen writes that “value is experience, not expectation”, I wonder whether what seems helpful about this statement risks becoming overshadowed by an apparent attempt to define the indefinable. I say “apparent attempt”, because the structure of the statement suggests “I’m going to tell you what value is”, even though his article suggests almost the entire opposite.

We Only Converge Towards Agreeing On Value

I understand Jurgen’s thesis as a variation on the old saw that customers often don’t know what they want until they try to get it (“experience”), therefore you probably shouldn’t merely try to give them what they ask for (“expectation”). On this point, I believe we agree entirely. Jurgen’s stories illustrate some of the original points of Lightweight/Agile software development:

We guess up front about what we want and we generally feel overconfident about our guesses. (Therefore we need to train ourselves to seek feedback and change our plans when we guess incorrectly.)
We often don’t know what we’ll notice missing from an experience until we’re having it. Even some of the things that delight us at the beginning of an experience become forgotten details by the end of the experience. (Therefore we need some amount of “live trial”—putting running software in the hands of genuine users in their true context—to challenge our best guesses about how our market will react to what we offer them.)
We often don’t know what we’ll appreciate from an experience until we’re having it or even after it’s over. Sometimes these are rationalizations. We often end up loving what we expected to hate and ignoring what we expected to love. (Therefore we need to train ourselves to accept the inevitability of changing our minds. Making this less expensive and less frightening seems like a helpful ingredient!)

While Jurgen sees the common thread of a person’s experience as opposed to their expectations, I see another common thread: we can really only converge towards agreement on value over time. We can only guess about it up front, we can only discover it as we go along, and we might never understand why people love, hate, or ignore what we offer them until we do it. Neither do they. And they’ll act differently on a Thursday, anyway. (And they’ll insist they’re perfectly rational in the process.)

You might argue in favor of something like the Steve Jobs “reality distortion field”, but I can’t tell the difference between that as a repeatable skill of genuine genius, as a consequence of masterful manipulation and bullying, or as an example of luck that belongs on the Wikpedia page for “Survivorship Bias”. Can you? It takes 35 years on average to conclude with 95% confidence that your mutual fund manager is good or lucky and by the time you can can do that, the information is of very limited value.

In this environment where value remains elusive and we can at best hope to converge towards agreement about it, it makes a lot of sense to me to do at least these two things:

Let others decide for themselves what value means to them.
Help them manage the risks associated with embracing the resulting uncertainty.

And this is precisely what I think agility/Lightweight thinking does well in its various forms: Extreme Programming, Theory of Constraints, Real Options Thinking, Systems Thinking, pick your favorites. And that’s my commitment to you: to help you create an environment in which you can (reasonably safely) understand better every day what value means to you while you still have time, money, and energy to do something about it.

I’m not even guessing yet at Jurgen’s intentions and I notice other things about this paragraph, but these are two of the things that I notice.↩︎
I mean complexities here. There are feedback loops everywhere! I experience value as a very nebulous and ever-changing thing—and that’s before I even look beyond what’s happening in my own mind!↩︎
It sounds perhaps “true, but useless”. To be true, it needs to be too general to provide any practical insight.↩︎