We change-harvesters say human, local, oriented, taken, and iterative. We talked about human a couple of day ago, let’s take on local.
A quick sketch of the idea, and a couple of cases will do, yeah?
Previous Post: Change-Harvesting Emphasizes the Human
I write about geekery as a kind of comforting respite from other concerns. But those other concerns are far more important.
Black lives matter. Please help me support and empower this movement for equity and peace. Stay safe, stay strong, stay kind, stay angry.
When we say that we want our changes to be "local", what do we mean? I think in terms of two nearby metaphors, "neighborhood" and "reach". We want our changes to be in the neighborhood, and we want them to be in easy reach.
Of course, "small" comes to mind right away, but it has its problems, most notably that it almost immediately prompts one to think of numbers, which tends to fire us off into a numbers game that distracts from the fluidity and flex of the idea.
The contrasting approach to local is global. Remember the early eco slogan, "think globally, act locally"? That notion of locality is what we’re aiming at. (When we get to oriented change, we’ll see the other half in action, too.)
A locality-in-action idea is "ENOF", which means "Easiest Nearest Owwie First".
It says, look right around you in the nearby environment, find something you want to change, make it something you can easily change, then change it. Rinse, lather, repeat.
This is in stark contrast to the default idea of how/what/when to change things. Our normal take is to say "what’s the biggest problem?" Of course, big problems aren’t easy to fix, and often tho not always, they aren’t remotely nearby.
ENOF — locality — says we’ll get better and faster results in our changes if we make them in a small neighborhood around us, and we choose the easy ones, and we just keep doing this, over and over again.
(A curiosity to me: old-school geekery is obsessed with over-simple addition of things that aren’t actually addable in any straightforward way, but the one place where they add pretty well is in making small changes, and that’s the thing old-school geekery routinely ignores. 🙂 )
A negative case: the overwhelming majority of so-called agile transformations are planned & executed as vast global changes, and have led to the widespread use of the phrases like ‘Big Agile’, ‘Dark Scrum’, and even just ‘"Agile"’.
Agile transformation as commonly practiced is a system-installation thing, like getting a new fiber installation in your building. It’s all or nothing, it’s all at once, it’s all now. And it does tremendous damage.
Many of those who founded the movement, or those like me, who were in that first ring of adoptees, are horrified by this. Our vision was one of community and collaboration, in fact we somewhat naively took it as a given. The global agile transformation is anything but.
What is it about these global approaches to change that make them fail so frequently?
The shorthand for it is complexity, in the complex systems theory sense, but let’s expand that a little, not just taking for granted we know what that means.
1) Multi-agency is spread throughout a software development system.
There isn’t one guiding mind and motivation, there are as many (or more?) minds in the game as there are players in it. This single factor alone guarantees that global change will run up against local agency.
2) Multi-layered multi-directional causality is present, too:
Detail A affects higher-level B, which affects sibling higher-level C, which turns right around and affects detail A. Unlike machines, human organizations have bewildering causal connections arranged in strange loops.
3) Global change has to go everywhere at once, which means its pre-conditions have to be everywhere at once.
The greatest of these is understanding the change, which is almost impossible to obtain by words or rules alone. Global change runs smack into local interpretation.
4) Efforts to abstract away and simplify all that complication, to render the human enterprise as capable of single-agent single-causality single-interpretation — "all models are wrong but blah-blah-blah" — don’t stand a chance, no matter how brilliantly powerpointed.
Because of the global approach to change — and other factors, too, some other time we’ll tackle that — the business of "agile transformation" sits somewhere in reputation between "used car dealer" and "gold dripping ambulance chaser".
Positive case: large-scale transformation of a TDD’d codebase by alternating steps of refactoring and extension, each step a modest local change, each step a confirmed same-or-better from its starting point.
The modern synthesis combines three activities to change code successfully 1) we test the code in tiny chunks, 2) we refactor the code, preserving its behavior via our tests, 3) we extend the code, extending those tiny tests. All three activities are highly local in scope.
What are the factors that make this emphasis on locality so successful?
In the same way that global change founders on several fronts at once, local change succeeds on several fronts at once.
1) Agency is restricted in one way and completely free in the rest: if you don’t make the existing tests red, you can do anything you want.
I have seen teams tell someone in their first week: go add this one test, make it pass, and don’t break any of the others.
2) Multi-directional causality is still there, but it’s much more managed.
The system stabilizes after each local change before we go on to the next one. This gives us a chance to observe causality instead of just theorizing about it.
3) Local interpretation is backed by the tests themselves.
They form a kind of executable documentation, and they don’t let us overlook details or smudge the meaning of words.
4) The elapsed time of a change roughly approximates its locality.
Local changes are of small period, typically under an hour. The benefit we gain from this returns to human-ness in several ways. See previous articles on "Many More Much Smaller Steps".
You start to get a sense of how important locality can be. Absent locality, we get Dark Scrum et al. With locality, we get a kind of dynamic unity, a thing that seems to stay "the same thing", even as it changes in nearly every respect. Another word for dynamic unity: "living".
Now, don’t go off half-cocked: nothing in life is free, except, somewhat regrettably, and maybe even temporarily, 99% of my content.
Locality isn’t free, either.
It takes technique. It takes practice. But above all else, it takes the recognition that it is such an important factor in most successful change. You have to see this to start acting on it, and my goal in writing about change harvesting is exactly that, to give you tools to see.
One final point: Locality introduces a problem. If I restrict myself to only small changes, I am implicitly or expliciting plotting a path towards a larger change, yes? How do I relate these two scales?
The next topic we’ll discuss, oriented change, will tackle that challenge.
Change-harvesting: human, local, oriented, taken, and iterative. Today we spent time with locality, a sense of neighborhood, of action "within our reach". If you want successful sticky change, in nearly any domain, focus on getting to locality.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.