Scrum is just a simplified process for applying some of the principles behind lean manufacturing to software engineering. One of the core principles of lean is - minimize work in progress (WIP). Sprint's are just a way of minimizing WIP.
Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded.
A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.
I think that this is a critical point to understand and it highlights why Scrum has been so successful. We know from research in the 80's, and 90's 90% of Software projects failed, due to things like poor estimates or wrong requirements or delays.
Agile/Scrum has addressed a significant portion of those concerns by introducing lean processes. This visibility has enabled the business to understands what is happening in the SDLC quickly and can reprioritize and redirect if things are no longer matching expectations.
Where Scrum tends to fail (IMHO) is that it doesn't integrate well with other business units. I think the industry needs to focus on release management (predicting outcomes) as a process to help marketing teams, sales teams, etc... if they need to know what is happening in the next quarter, etc...
Either that or everyone needs to wait until engineering is finished before talking about new features (sounds a bit like the tail wagging the dog)
Why minimize WIP? Because WIP holds the risk that you're building the wrong thing. In manufacturing this might be using flawed parts that won't get tested until later in the process or it might be building inventory that you ultimately can't sell because the market demand has changed. In software WIP risk could be a misaligned understanding of the requirements; a flawed view of what minimum viable product looks like to the target market or a technology stack decision that represents a performance dead-end. In all of these examples you want to find out if you've made an error as soon as possible because if you're wrong then all of the WIP may need to be discarded.
A smart team holding to the core lean principles should feel empowered. Arguably Scrum, in it's dis-empowering form, is just another process to help manage mediocre teams.