Thread by @GeePawHill

Now we've seen these basic ideas, human, local, oriented, taken, and iterative. I want to use them in a particular way for a bit. Let's take some practices we know we like, and work backwards, seeing if/how these "known-goods" relate to those ideas.

(My muses become blogs and podcasts, but that takes a while. If you want to catch up, this is the previous one, and its backlinks will get you back to the beginning.

threadreaderapp.com/thread/1234181…

Want it all, don't care when? Go to geepawhill.org and subscribe today!)

Let's talk about "Working By Stories" for this first one. I'll describe what I/we mean by that, and then we'll try to look at it through our change-harvesting lens.

I had thought to do TDD & Refactoring first. But working by stories has some advantages. It's a smaller topic, it doesn't involve us in a lot of technique arguments, and it seems to be more widespread in adoption.

Change-harvesting is expressly *not* limited in scope to code & coding. It's not a new technique for programming, it's an outlook and a concomitant strategy for successful change in complex adaptive systems. Using stories as our topic seems just right.

Working by stories goes like this:

1) On the first day of work, and then forever after, we have a program. We believe that program is insufficient, that it needs to change. So we describe our change as what we call a "story".

2) A story is a kind of lightweight conversational "placeholder" for us, an imaginary object. It's a token that we use to structure, plan, and distribute work we haven't done yet.

3) The "weight" of a story is important. It is little more than a label and a sentence or two expanding on it. Stories are so featherweight we routinely use 3x5 cards as their physical representation.

4) The primary *use* of the story is in the interactions of the team. Before a story hits the "do this now" threshold, we use it to structure conversations about relative importance and difficulty. Once at that threshold, we use it to talk about what we're doing & how it's going.

5) Stories gain weight as they approach "do this now", as they pass it to be "work in progress", and in the end, as they "ship". But the greater bulk of that weight is not in the story -- the token -- but in the minds of the team.

So let's talk about human, local, oriented, taken, and iterative in this context of working by stories. Along the way, I'm prolly going to throw out some controversial sparks: in my view, as widespread as the practice is, stories are misunderstood and misused widely in the trade.

Interestingly, with most of these concepts, I get a strong sense of why stories work well, when they do, and why they don't work well, when they don't, based on just those words.

In the days before we started using stories, we described our work using very large and quite heavy "requirements documents". Stories are not requirements documents, and in describing how and why they're not, we might get a better sense of all this.

A requirements document is a 100% complete description of a 100% completed program. It is "final" in its orientation. It does not describe a path, only an endpoint.

When a requirements document is used, it's meant to be rigorous, detailed, and non-negotiable. They are contracts-for-code, and were in fact attached to contracts-for-money as supplements.

Stories, on the other hand, spend most of their lifecycle being partial, vague, and flexible. They are nearly useless as attachments to contracts-for-money, and they don't describe anything final, but only a single step, applied at a certain time, to a particular program.

Stories have a great deal of locality to them. Remember we said that locality was about the size of the neighborhood? The ideal story is local in several neighborhoods.

First, a story is local in application time. What I mean is that a story is always applied to a program at a particular moment in time. The same story, applied at two different times, can be easier or harder, more valuable or less valuable, riskier or safer.

This is why starting a project by listing a thousand stories, estimating them, and lining them up in a huge backlog, amounts to a lot of wasted effort. The stories themselves, the estimates of value, risk, and difficulty, all of that is *very* likely to be wrong.

Second, a story is local in execution duration, how long it will take us to do it. In fact, getting stories small enough is by far the most difficult part of using them. The sweet spot for execution duration is on the order of 1.5 days of team effort.

By far the most common mistake newcomers make in story-writing is to ignore this severe size-constraint. It usually comes from one or both of two factors: 1) simple inexperience at story-splitting, 2) using monovalent analysis based strictly on "users will pay more for it".

Third, a direct result of that second element: stories are local in mental bandwidth. That they're so small in duration is tightly coupled to "how hard is it for our minds to both grasp and execute what needs doing". Here, as so often, local and human align favorably.

So, did you see what happened there? We slid from "local" to "human". This is entirely normal with this conceptual framework. You can't think of the five words as describing a five-dimensional space. It's more like a spreading activation network, or a tensegrity sculpture.

Each item relates or activates or partially-determines, the others. This, by the way, is part of why I take so much time explaining the change-harvesting approach. It's not an algorithm and it's not a machine, it's a stance, a worldview, a way to see and be.

That bit about local in application time, here we slide once more, this time to "taken". Taken has multiple layers, we'll see another one in a bit, but one of them is just working with what is there. Stories, applied in time, work with the program that is already present.

A story is about a *change*, and we can't ever talk about a change without talking about what we start with. This is one meaning of that word, taken.

Of course, that size constraint strongly implies "iterative". The simple fact of the matter is that 1.5 team days isn't very much time. If we're going to work in chunks that small, and we want very much to do so, we're going to have apply changes to things we've already changed.

This is closely related to things like "evolutionary development" or Cockburn's "walking skeleton pattern. These are ways to think about iterative approaches.

So much awful process failure, not just in working with stories, but all over the trade, is based in the fear of iterative change.

"Rework." Boo!! Scaredja, dint I?

Iterative and local leads quickly to the idea of oriented. In the oriented approach, we have in mind a distant goal, out on the horizon. We turn to to face that horizon, then we act, right here and right now. What's another name for that? Well, how about "working by story"?

Every story we add to our app is a full, completed action. Every time we finish one, we get multiple kinds of value. You know that mantra, "stop starting, start finishing"? Framing our work in stories helps us do this effectively.

Finally, we come to human. Working by stories has *many* aspects that lean towards human strengths and away from human weaknesses. I'll just mention a few of them.

Remember that a story is just a token, a placeholder for a series of conversations. Compare and contrast that to a requirements document, which is meant to end conversation.

The single most obvious human attribute is our crazy-mad skillz at direct peer-to-peer conversation, and stories absolutely utilize and indeed rely on just that attribute.

To me, the key failure pattern of the JIRA-fication of everything is the extent to which teams think it is a valid substitute for direct social interaction between humans. It would be to laugh, if it weren't so pernicious and widespread.

Stories are "conversation handles". That is what they do, they give us a way to grip an entire set of interactions between ourselves.

We already touched on the local -> human connection of bandwidth, but let's say it again: the hard part of changing software is the thinking. Obsessing over the size of our stories is minimizing the number of simultaneous "concepts in flight", things we have to hold in our head.

Stories have another human-centric aspect: they support two of the important colors in the human motivational spectrum: Rhythm, and Purpose. (See geepawhill.org on the RAMPS ideas.)

Stories provide focus to our conversations and our other activity. As such, they are also providing an element of purpose, a sense that our effort is in service to something bigger than ourselves.

They also provide rhythm. When we start a story, we enter tension. When we finish it, a couple of days later, we experience release. Alternating periods of tension and release are of enormous benefit to humans, in both body and mind.

So there you go. We've been "Working By Stories" for two decades. Some shops do it well, others less so, but it is a "known legit" practice. It is human, local, oriented, taken, and iterative, exactly as a change-harvester would have predicted.

Normally, this is where I plug my site. Today, and for the next while, I have a more important request. I'm GeePaw. My GeeKid, Threy, needs some financial help I can't give just now.

If you like my work, do me a solid, and go to gofundme.com/f/rip-jason-an…

Help if you can, please.