Improvement resistance

Recently I read a twitter thread by Ron Jeffries Original tweet Threadreader

(This is the head and tail if you didn't notice)

There was a bunch of replies which didn't answer his question, and some that did. Naturally, I started thinking of something slightly different and would as such have given another non-answer.

Now that I've noticed this, I'll first try to answer the question - and then put my sidetrack in another article.

Why do teams doing "scrum" not improve their situation - even though they see the problems?

First: Perspective

Maybe they do not actually see what you see. You see uncompleted work, they see someone dumping in work into their sprint. Now, a team can do something about that, but it might not seem that way to them. As in, they cannot improve because the solutions are outside the imagination of the team. They might be searching for "how to fix a bad boss" while you're suggesting "how to fix bad forecasts".

Second: Cost vs benefit.

Trying to improve has a (perceived) cost for a (speculated) benefit. When the scale tips heavy on the cost side, people in general will not do the improvement.

The key here is Perceived cost - the actual cost is most likely different. But if you have tried to improve before and all you get is backtalk, the perceived cost for future attempts seems to rise drastically. Previous failures can add more perceived cost in the future as well. This is, in my experience, usually what drives the backtalk to begin with. "No, don't do that because we'll only get yelled at by management again". Or "We'll get reorganized within 6 months anyway, so nothing we do in our team will have a lasting impact". This is of course not strictly true - there's no guarantee that you will be yelled at, or that what you learn until the next reorg can have impact beyond it - but humans like to simplify and see causality where there might not be any.

The Speculated part of the benefit does not do much to help either. If you have not experienced how great improvements a team can make then you might (will) underestimate the benefit, hence tipping the scales further in the wrong direction.

In summary

This is one of the hard problems in tech (and not exclusive to tech) - people. We're comparatively good at solving programming problems, but not so much people problems. Why? Programming systems may be complex systems, but people are complex Adaptive systems (as are teams, companies - because they're made of people), something programmers are generally not used to. Something I think is not taught to most professions. Standard programming approaches do not work (or any reductionist approach). Complex adaptive systems change in response to being observed and the human observer may change in turn. Empirical approaches seem ineffective (because causality is not easy to deduce) and in general, people turn to experience, "gut feel" or theory instead.

There is a lot more to this, because people are complex. But I provide only a small seemingly causal link, because I'm human. Hopefully though this can add one more part to the over all complex answer to Jeffries question.