It's not a theory though: it is a collection of strategies. A theory would propose a cause-and-effect model with testable outcomes.

Scrum's proposes strategies are based on unstated assumptions. E.g.

"Scrum employs an iterative, incremental approach to optimize predictability and to control risk".

The assumption there is that Scrum's roles and events will do that. But there is no theory in Scrum that says why it will.

In fact, Scrum's events are at substantial variance with what we know from actual research in behavioral psychology, cognitive science, and other fields. For example, the daily Scrum is a process that is very challenging to some people cognitively: it feels like an interrogation, and some people don't think well on their feet under time pressure with the whole team staring at them.

Scrum's iterative approach is a mismatch for the natural flow of intellectual work. Unlike physical labor, product design and development don't neatly fit into fixed time increments. When I have been on Scrum teams I always loathed the end of the sprint, because I was always deep in the middle of finishing something, and I had to stop and put it aside, and when I eventually got back to it, I had lost the momentum and many of the ideas I had for what I had planned to do.

Scrum's many "events" are actually anti-patterns for how people work best. In each case, there are better ways. E.g. for transparency, all you need is an inquisitive team lead who checks in on people and asks the right questions. Scrum tries to replace good leadership with mechanical processes - just like PMI did. It doesn't work. What works - the only thing that works - is having effective leaders. We should be teaching people how to be better leaders, not how to run a Scrum feature factory.