Scrum is inherently a rat race. And if you don’t believe it, then read this article by Jeff Sutherland. It reads like a chapter out of Taylorism. And his comparison of a programming team to a fighter airplane is idiotic: people are not machines. His view of a team is highly non-Agile.

The points in Willem-Jan’s article are all true. Organizations use Scrum to pressure developers, and create a relentless cadence without a break. And they often do all the destructive things that the author says.

But “team happiness” is not a basis for deciding what to do tactically in a for-profit company. One needs to look at long term effectiveness, and consider “happiness” (morale) at a strategic level. One cannot expect managers — who themselves are under pressure — to make decisions based on what makes the team “happy”.

Thus, instead of making “team happiness” a day-to-day decision criteria, organizations need to define processes that don’t burn people out. For example, the organization could decree, from high up, that every fifth sprint shall be a refactoring sprint with no backlog. That needs to be a rule.

Scrum can be adjusted to make it work better; but out of the box, it is horrible. The leadership model is broken, the performance model is broken, it does not say how it should work in a large organization that has governance concerns, and it does not say how to work with technical subject matter experts. It also does not work well for complex systems that require teams to specialize in portions of the overall stack — something that is considered a best practice for microservices.

It’s time to stop assuming that Scrum was blazed into a stone tablet on Mount Sinai and that it therefore must be perfect, like some mathematical truth. The notion of a process control system is ad-hoc nonsense — again, people are not machines. Scrum is terribly flawed, and is broadly inadequate in most situations — and yes, it tends to burn people out unless you change Scrum or add additional rules.