We’re talking about change-harvesting: human, local, oriented, taken, and iterative change. Let’s consider this adjective "taken" today, and see where we go with it.
I keep saying: these muses are respite for me, and maybe for you, from more important stories.
Partisan thugs seek to turn our nation into a freak show of state violence, white supremacy, vast inequality, & the oppression of women.
Stay safe. Stay strong. Stay angry. Stay kind.
In change-harvesting, we use this word "taken" in multiple senses, but to put it in a single sentence: the change-harvester takes both the substance of and the approach to change from what is already there.
We take our changes from here, we don’t give our changes to there.
To go from A to B, it is easy to focus all of our attention on B. The change-harvester is saying we can’t make effective changes unless we see them as changes, as transformations to A. And that implies paying a great deal of attention to what that A is and how it works now.
Although "taken" may seem a little shaded or obscure, it’s actually at the very center of what it means to change a thing, as opposed to building one. We’ve touched many times on the difference between greenfield & brownfield. With taken change we see that difference in action.
A negative case: An enormous software system for managing what is nowadays called "human services" casework.
It was double-digit millions in the making, spread across years. It is universally reviled by its victims, the human services pros who have to use it.
Human services work in the US involves a ginormous variety of specialist teams, with a huge clientele, and a set of ever-changing laws that make the tax code look like a primer. These people rely on inter-team collaboration, single-source-of-truth, and strict confidentiality.
This new system, been there for about a year now, was "given" to the people who use it. There were no direct consultations. No ideas were taken from the teams down on the floor doing the actual work. There were no intermediate or evolving products, just the big monster.
It is a classic old-school approach to change, and it violates most of the change-harvesting attributes, but it really fails primarily because it was not taken from the people who use it, but given to them. Let’s look at some of the factors in this failure.
- Because it was not taken from the experience of the users, it meets resistance at every turn. What they want is (maybe, barely) doable in the new system, but their resistance substantially slows their ability to see how to do their work effectively.
- Because it was in fact taken from a kind of Platonic statement of procedures rather than the lived experience of the users, it ignores every aspect of their job that is accomplished outside of those procedures. Those aspects are actually the core of the job, not a side-show.
- Because human services work has more exceptions than rules, a system that does not understand exceptions must be constantly and manually worked around, usually at higher cost than whatever systems the users had in place before the change.
- The most important aspect of inter-team collaboration is the coordination of cross-linked info about interactions with clients & other teams. This given system can’t do that. Their most important challenge remains unresolved. It’s just more useless heartache to them.
The upshot? The desired change, of increased collaboration, a single source of truth, and high confidentiality, has not achieved. To make matters worse, the system was built in violation of the other attributes as well, and can not be changed in the foreseeable future. Whoops.
(An aside: I took this case from government, always an easy target. But I have seen the identical case in myriad corporate settings as well. I just found this case easy to explain and discuss. Don’t make the mistake of thinking that for-profit corporations don’t do this.)
There are really two positive cases here: Retrospectives and refactoring, both of which are essential parts of the modern software development synthesis, are both wonderful examples of taken change.
In retrospectives, we gather folks together, as equals, and we take from them. We take ideas about what is working well or not as well as ideas about what might be better. And those taken ideas transmute directly into change.
In refactoring, we take our changes directly from the code, and, importantly, the behavior, that is already present. We purposefully restrict ourselves to just those changes that preserve that exact behavior. We do this expressly to make it easier to later alter that behavior.
Why are these two approaches so useful for us? There are several factors, but the key is that they are both centered in a taken approach.
- Action items emerging from a retrospective are far more likely to actually be performed precisely because they came from within the team, from its grasp of what is already there.
- Those same actions are also more likely to be correctly targeted. They tend to incorporate problems & solutions that are not already in the procedural mix. It’s because we’re not taking them from the procedures, we’re taking them from the team that utilizes those procedures.
- Holding the behavior fixed during the refactoring simplifies our challenge: we take the existing behavior as our constraint, and alter the existing code. The chaining together of successive refactorings in this way produces very powerful results in a safe manner.
- Refactoring heightens the signal/noise ratio of what is already there, before considering ways in which its behavior may change. In the A -> B world, it’s obsessed with the way the A code expresses the A behavior. This accounts for much of its success as a coding technique.
Both of these positive cases are examples of the taken in action. "Taken" re-balances our attention, from all being on an endpoint, even a nearby one, and instead distributing it so that the starting point receives at least equal attention from us.
Like the other attributes, taken doesn’t stand alone.
It reaches towards the human and the local, and ultimately it underpins the iterative. It’s hard to get at, but it really is the definition of "change", as opposed to "build".
When we change something, we are changing something. That something isn’t abstract or distant, but concrete and right in front of us. Change-harvesters make sure to focus there first.
Supporting GeePaw
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. You can also subscribe to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.