Some good points here.

I would point out though, that a non-technical view will lead to great misunderstaning. E.g., the article says, "In the last days of a sprint, everyone was rushing to deliver everything they had done in the previous two weeks"

Well, usually when this happens, it is because teams/individuals are not able to run tests when they really need to - e.g., integration tests are a good example. So they have to get that done later. Or they are waiting for other things to be in place - things that require manual action.

So really, the root cause is very, very often a lack of automation.

But a non-tech SM will see this in terms of a cycle time that will not reduce, or a WIP that needs to be reduced - but those are not the root causes: they are symptoms.

If you want to really make things work well, you have to understand HOW they work.

For more examples of this, see my article, "Non-Technical Agile Leads to Waterfall" - https://www.linkedin.com/pulse/non-technical-agile-leads-waterfall-cliff-berg/