The Change-Harvester’s Value

The change-harvester’s take on “value” is quite different from the software trade’s “standard” view. To get at that difference will take us a little time.

Three differences stand out for me just now, and they have to do with 1) definition, 2) distribution schedule, and 3) temporal stability. I want to take a look at these in a particular context: "the long story".

(Aside: I’m mildly sick today, so it’s gonna spill out a little more slowly. It’s dumb to work when you’re sick, but you don’t understand: I want to go out for dinner & drinks this evening, so I need to override the “too sick to go to school, too sick to play” tape in my head.)

I’ll characterize this long story as a chunk of work that is six weeks long. I actually think a long story is any story the team can’t deliver in “a good day and a half”, but I’m not looking to debate that for now, so I’m picking six weeks.

I know that six weeks is the right number to call “long” in this context, because on the one hand, many of my followers would cheerfully agree, but two, some of my followers work in orgs in which “work chunks” of six weeks are commonplace.

So we’re talking about a straight line in time, six weeks long, and at the end of it there’s a finish line, and a “value” is achieved.

That value, in the traditional model, is quite narrowly defined. It is “an attribute of the product that a user can detect as a feature of the product that is both finished and desirable”.

Saying that definition of value is narrow is saying that it excludes things that are value but aren’t being considered.

First, it excludes some pretty important stakeholders. I won’t list them, but certainly the makers, those people who directly craft that story, the management, those people who guide & support the makers. There’s more than that, but let’s keep moving.

Second, it excludes pathing. This definition is focused on one thing, an endpoint. But to get to an endpoint, one must perforce travel a path. This value definition ignores the path almost entirely, tho there are always multiple paths, and picking a good one is valuable.

Third, it excludes or severely diminishes the value of relationship. Every user desires complete features, to be sure, but many and in some shops most of the users gain value by both directing and experiencing the gradual elaboration, the development, of a feature.

A change-harvester understands the org as a dynamic unity, an engine for making changes and harvesting their value to make more changes. “Value” is anything that allows that process to continue, including non-user stakeholders, pathing considerations, and relationship.

The next difference: the distribution-scheduling, which is about how we give the value to whoever’s getting it over time.

The six-week story has to store up the input value needed to do six weeks of effort, do that effort, then give out the value. 100% of the input value is gathered at the beginning, and 100% of the output value is gathered at the end.

The time between gathering the input value and getting the output value is regarded in the standard model as arbitrarily elastic. The length of “time to value” is irrelevant as long as input and output balance.

If you think metaphorically of taking a deep breath, holding it, and swimming underwater, you get the picture of both what that standard model is doing and why that model isn’t very faithful to reality.

The change-harvester knows that the maximum capacity of the lungs that take that starting breath is 1) decidedly non-linear and 2) actually quite modest.

Put another way, without metaphor, the stored value in a team decays quite rapidly, and must be replenished at very short intervals. Six weeks is too long. (BTW, six weeks is nothing, I pretty routinely see six months in a story plan.)

The third difference in how the change-harvester sees value is about the temporal stability of the value of a given change.

The six-week story doesn’t realize any value until six weeks from now, when we hit an endpoint. The challenge: being sure that six weeks from now that endpoint will have its expected value.

The change-harvester says the further we are from harvesting a value, the less accurate our assessment of its value. This lack of accuracy manifests in two ways: 1) the target seems to move as we approach it, 2) the target delivers less actual value than we hoped.

Further, and as usual with change-harvesters, we see this as non-linear: when we plot the degree of error against the distance to the harvest, the relationship is not a straight line, but a sharply rising curve. As the distance gets bigger, the error gets bigger-er.

So, the change-harvester’s sense of “value” has at least 3 differences from the standard sense of it, in 1) definition, 2) distribution schedule, and 3) temporal stability.

When we throw these in a barrel and shake it all around, you get a very different vision of how to proceed. Do you remember our long conversation about the “how” of change?

We said we wanted our changes to be local, oriented, human, taken, and iterative. Those adjectives, I hope you see, are richly intertwingled with these differences in how we see “value”.

The adjectives support the definition of value and the definition of value supports the adjectives.

Broadening our value definition allows us to go small — local — and lets us work better with our humans, actively taking our ideas from them and orienting towards more distant value, all while understanding that there’s no real endpoint, only an iterative process of change.

For now, I’m done. I have totally dominated the “too sick for school, too sick for play” tape, and will now rest until dinner & drinks time.

I hope you have a plan today that works to give you rest and reward, and pushes just the right value at just the right time!

---

---

The GeePaw Podcast

If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here. You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.