Human, local, oriented, taken, and iterative: this is how change-harvesting in software development approaches change in most contexts in the trade. Let's take "human" today, and see where it leads us.
Before we begin, I want to express my continued support for the protestors. They're still out there, folks, still peaceably seeking change, and still risking life & limb in the face of armed violence every day.

Stay safe, stay strong, stay angry, stay kind.

Black Lives Matter.
When we use that word "human", change-harvesters are getting at the fact that, in systems involving humans, machines, and procedures, the humans are the most powerful force. When we seek change while ignoring human factors, we go awry quite rapidly.
Human emphasis, in this usage, opposes both procedural and mechanical emphases. A common form of the problem is to implement a system using simple logic and uni-directional causality, abstracting away the complexity and sophistication of how humans actually perform at their best.
A negative case: I work with a lot of Scrum shops. During the planning of a sprint, we target some velocity value, pull stories adding up to that amount, and get folks to sign up for those stories. The sprint is a bucket, and we seek to fill that bucket during planning.
In many shops, this is Jira-fied, and is all tracked meticulously, establishing both the desired group velocity and the desired individual velocity. We spend a lot of time jiggling and analyzing numbers.
Later, when the sprint is over, we'll spend some time establishing a new velocity, and -- all too often -- "rolling over" work from this sprint to the next one, more or less grumpily and blamefully, depending on the team in question.
All of this makes the most wonderful sense, doesn't it? It's addition. It's logic. It's tracking. It's how machines and procedures work.

So then, why do I spend so much time watching it fail?

The change-harvesting answer to that question: we de-emphasized the humans.
Here are some of the reasons that de-emphasis on humans leads to unhappy and unproductive teams.
1) Humans aren't fungible, either across bodies or across time. That is, I'm not only not reliably interchangeable with you in terms of capacity, I'm not even reliably interchangeable with last week's version of me, not until we've gathered a great many weeks.
2) Humans like *very* *much* to impress & please the other humans around them. They routinely sign up for more work than they can do, for no other reason than to please the work-givers. (They also do it to feel like they're "equal" to the others on their team.)
3) Humans like winning so much that they're perfectly willing to win "on paper" regardless of whether they win "in life". That means that, as the sprint approaches its end, they'll rush, overlooking risks, in an effort to satisfy their targeted capacity.
4) Humans like helping, too. In most teams, there are very strong geeks who get to work on their own problem half as much as the others do, because they spend so much time consulting and assisting on the others' problems.
5) Humans aren't remotely as productive when they perceive themselves as failures. When we routinely push our capacity limit, we'll routinely fail to hit it. And when we routinely fail, we routinely produce less effectively.
There are a bunch of reasons why the simple logic of Scrum's sprint planning doesn't work well for many teams. And what they seem to come down to is this: it de-emphasizes the reality that the humans & their vagaries are the most powerful factor in our success or failure.
A positive case: once teams build their pairing skills, the pairs routinely out-perform their old all-solo-all-the-time performance. We've seen this over and over.
I rush to say: *once* they build the skill. Pairing (& mobbing) is a skill, and like all such it takes practice. I've seen all too many teams rush into forced all-pair-all-the-time to disastrous effect: yet another cost of ignoring human factors, by the way.
But why does pairing/mobbing work so well? Again, there are several factors in play, each bearing some of the responsibility for the improvement.
1) Once again, humans aren't fungible. My skills and your skills are different skills. Pairing & mobbing takes advantage of this by putting our overlapping-but-different skills and attitudes in harness on the same problem at the same time.
2) Humans also still like winning. Pairing and mobbing emphasizes wins and de-emphasizes losses. Another case of the math making no sense: the benefit of a shared win is as high as a solo one, but the cost of a shared loss is *lower* than a solo one.
3) Humans are very often out-of-phase in energy. When you're feeling it and I'm not, that's the perfect time for you to carry our pair for a little bit. Not only does the *pair's* combined energy stay comparatively stable, but your energy often stokes mine. Humans work that way.
4) Humans enjoy both teaching & learning. When they work with other humans, they get many more opportunities for both. We've long documented the extremely rapid skills transference that pairing & mobbing deliver.
5) Humans are social creatures through and through. Though there is a broad range of communication skills & styles, it is still the case that the majority of humans greatly value direct engagement with others. The programmer-as-lonely-wizard motif was played out a long time ago.
Pairing and mobbing, once again, don't "math" very well. Our earliest ideas about it seem to imply that we'll be half as productive in a pair, but that just isn't the case. What gives? The activity emphasizes the peculiar strengths of the humans engaged in it.
I hope, through these two cases, you're getting a feel for that first pillar in the change-harvester's mantra: we "lean in" to the humanness of our most powerful force, and "lean away" from the procedural or mechanical forces.
There are many other cases we could mention, and since the five terms overlap, we probably will be bringing some of them up later, but for now, we have a start: change-harvesters pay particular attention to the humans in a system in their approach to change.
Thanks for reading. Two favors I ask:

1) Subscribe. It's free, spam-free, comes twice a week in full-text or as a podcast.

2) Keep working for & supporting change, in the trade & out. We can fix this. We're the only thing that can.

Black lives matter.

geepawhill.org/subscribe

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

6 Sep
To make the case for Change Harvesting as an approach, it's important to understand that the cost of Rework Avoidance Theory isn't imaginary or subtle, but both concrete & quite high.
Geekery's not the most important story for me right now, it's really just comfort food. Rest, but don't get distracted.

Black lives matter.

Stay safe, stay strong, stay angry, stay kind.

We can change this. We're the *only* thing that can.
The most essential aspect of the RAT (Rework Avoidance Theory) is its emphasis on the endpoint: the City On The Hill we call it.

The central concept: define the City rigorously, optimize building it off-line, move in to it only when it's done, and never change it again.
Read 33 tweets
30 Aug
Change-harvesting software design centers "online" brownfield development: change-centric thinking. Most older sets of design imperatives are based in "offline" greenfield development: build-centric thinking. The differences can -- and should -- lead to design disagreements.
This week, regular like clockwork, we shoot yet another unarmed Black man in the back, and we quietly arrest a white man carrying a long gun he has just used to kill people.

Stay safe. Stay strong. Stay kind. Stay angry.

Help us change this.

Black lives matter.
The significance of "online brownfield" vs "offline greenfield" is hard to overstate, in all areas of software development, but especially so when we talk about what makes a design "good" or "bad".
Read 35 tweets
23 Aug
When we did our compare & contrast of the working models underpinned by Change-Harvesting theory (CHT) vs Rework Avoidance Theory (RAT), we temporarily sidestepped the specific differences of the implementation part. Let's drill in on that today.

threadreaderapp.com/thread/1296122…
It was *quite* a sidestep: other than the implementation part of the two models, they have much in common, with the key difference being the highly iterative nature of CHT's approach.
If we squint a little, & we don't talk implementation, we can see the CHT model as being a daisy-chain of RATs. Each step is a "mini-RAT", on a scale of a couple of team-days each.

But that's *only* if we ignore implementation differences. And they're too big to ignore.
Read 31 tweets
19 Aug
Let's compare and contrast the RAT (Rework Avoidance Theory) model of software development with the CHT (Change Harvester Theory) model. The differences are multiple and pronounced, so this may take us a while.
It is not rote for me: there are many more important things to be doing right now than geekery. I'm actively supporting my friends & family out there seeking equity in the streets.

Stay safe, stay strong, stay angry, stay kind.

Black lives matter.
I want to talk not so much about the theories today, as about the working models they underpin and lead to. Those models are a kind of inner core of making software, shaping our activities of course, but also our solutions, and even the problems.
Read 36 tweets
16 Aug
A flow app, one that steps the user through an acyclic graph, typically gathering info at each stage, can be built to provide iterative user value by gradual refinement. Let's look at how that's done.
Before we get into it, for me, and maybe for you, too, geekery right now is not the most important story. It's just comfort food.

If you're out there working for change today, I support you wholeheartedly.

Black lives matter.

Stay safe, stay strong, stay angry, stay kind.
The standard flow app is when we walk the user through a complex operation, and we gather the pieces step by step. Though it looks like a straight line to any given user, the answers in previous steps actually shape the following steps, hence the directed graph under the hood.
Read 25 tweets
14 Aug
A lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account.
Before we proceed: Changing a software development process is kind of a sideshow to me right now. Changing the world out on the streets is the real story.

Black lives matter.

Please go make real change, and stay safe, stay strong, stay angry, and stay kind.
People ask me why the change they're trying to make doesn't happen. The questions come from all levels of an org, from the very top to the very bottom. "Why won't they change?" It's often accompanied by an implicit theory. It's often aimed at me because I have had some success.
Read 27 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!