Hi David.

I watched Scrum steal the Agile movement during the early 2000s, with horror. And IMO, Scrum nearly destroyed the movement — it might have, as Agile is certainly being challenged today for “not working”. I blame Scrum for that outcome. Let me explain why, and then I’ll answer your question about Scrum itself.

Scrum existed before the Manifesto. It is not well aligned with the Manifesto (I will explain below). But Schwaber and Sutherland were at that meeting where they came up with the four values, and afterwards they saw it as an opportunity to claim that their Scrum process was aligned with the Manifesto (it is not, which I have promised to explain three times now!)

Then Schwaber launched a cheap certification after which one could claim to be a “master” (Scrum Master). Organization leaders did not understand the Manifesto and so they very reasonably assumed that if they brought in people who were “masters” in something claiming to be “Agile”, then they would become Agile. And those selling Scrum did nothing to explain that that would not work — they happily sold their certs.

Of course it did not work, and eventually we started to hear “Don’t do Agile — be Agile” and “You have to have an Agile mindset”, but those were not explained. They were more bumper sticker maxims, like the Manifesto, which has its own problems for being too simplistic.

The army of newly minted Scrum Masters, many of whom had no experience building systems or managing people, having created new careers around Scrum, self-identified in a personal way with being Scrum Masters, and became evangelists for Scrum. The Scrum Guide says that if you change Scrum at all it is not Scrum, so none of those who identified strongly with being Scrum Masters would change it: they were Scrum personified.

And so the Agile movement froze around Scrum. It could not evolve. We saw the rise of the “Scrum Nazi” or what the British Computer Society called “Scrumdamentalists”.

But Agile needed to evolve, and so we started to see offshoots. DevOps was one of them: it became a separate movement, and so today people who know DevOps generally only know the very basics of Agile, and most Agile coaches know almost nothing about DevOps. That’s a huge dysfunction.

Eventually people realized that Scrum is not so great. David Anderson promoted Kanban, which I personally find is a much better fit for Behavior-Driven Development. But that’s another story.

As to why Scrum itself is not aligned with the Manifesto,

1. It is prescriptive: people who have the job role Scrum Master are dissuaded from changing any of the Scrum practices, because the Guide says that if you do that, you are “not doing Scrum”. You can add, but not alter. So instead of Scrum being defined as a collection of ideas, it is defined as a rigid set that you are encouraged to use in their entirety.
2. The PO role is one-directional. Scrum does not assume that developers will have ideas about what a product should do. Yet, when developers meet actual users and learn how the product is being used, they often have amazing ideas.
3. Scrum misses entirely the important element of product design. It is often very effective to have a separate product design team working in parallel, collaborating with the development teams.
4. Scrum obsesses over “the team”, and yet most products have many teams. Simply saying you should have a Scrum of Scrums does not cut it. Most of the important issues are product related, not team related.
5. Scrum’s insistence that there are only three roles makes no sense. Effective teams usually have a tech lead and a team lead. They might have a data lead too. The presence of these roles is very helpful, as long as those individuals use positive leadership styles, rather than autocratic styles.
6. Scrum has drastically redefined the role of Scrum Master at least seven times. Not small changes — major reimaginings of the role. So why should we trust them? They clearly don’t know what they are doing. In fact, Scrum misunderstands the role of leadership in teams and in collections of teams. The model of “servant leader”, which is where their more recent attempts landed, is insufficient. Servant leadership is appropriate in some situations, but is by itself insufficient in a product development team: other styles of leadership are needed. As Peter Drucker said, “you need an inside person, an outside person, and a person of action”.
7. Scrum’s practices are a huge distraction from what matters. What happens is that SMs obsess over things like story splitting and the standup, but if I were to create a list of the top ten things that really matter, Scrum’s practices are at the bottom or not even on the list. And so what happens is that the team becomes exhausted talking about those practices, and they don’t focus on the things that matter — things like their cycle time and product incident rate.

I have just scratched the surface. Scrum fans point to “empiricism” but really? Is that the argument for Scrum? Something so fundamental to all of engineering and management? We don’t need Scrum to be empirical — to define OKRs or use data or be hypothesis-driven.

And then there is fact that we just don’t need Scrum. I have been on teams that were extremely effective in which not a single Scrum practice was in use.

If it works for you that is great; but just know that Scrum is not necessary to be successful. I know that for a fact.