Read on Twitter
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.
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.
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.
