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.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.