“In the real life you always has to manage the different risks: …”
You are right. But how are problems like these (I would call them problems because risks are something that might happen or not) specific to Scrum? Run a waterfall project with unexperienced people or with people who have the wrong qualification and you’ll end up in trouble and with very low predictability. But when you do Scrum you’ll discover these problems right off the bat, probably in the first one or two sprints. And then you can react. With waterfall you would be hoping for the best until rather late in the project — and then you have no chance to really turn the shop around.
I had the exact situation in my last project: too few frontend developers and expertise in Solr lacking. I was able to show the results of the first sprints and escalate this to management. It was not easy but I got the needed people and we were able to finish the project on time and to the customer’s satisfaction. Had we done waterfall that would never have happened. (And that is, by the way, what I would call the built-in risk management process of Scrum.)
