Can you use Scrum even if you are buying something well defined with a fixed price and fixed scope?

The answer is pretty simple: if you can predict the cost and the scope, you are not doing anything complex. If you aren't doing something complex, you don't have a reason to use Scrum.

Even if you like the Scrum cadence or the roles that Scrum has or how Scrum frames the customer and developer responsibilities, it would still be mostly waste and window dressing to use Scrum when it's not necessary. Most of the Scrum ceremonies would just deflate into unnecessary status meetings that could have been emails.

In agile lingo, being complex is not just a word that is used for a large or complicated or risky things when they get large or complicated or risky enough. Being complex is a qualitatively different category of situations: in a complex situation, it's fundamentally impossible to predict things in advance. You tweak one aspect of a thing thus, it causes unexpected effects in another seemingly unrelated parts. Next time you do it, it maybe doesn't.

There are too many variables to map or predict, so trying is basically a waste of time. You can only try things out, see what happens and then use that information to make more informed guesses on what to do next.

Sometimes things aren't complex, though. They are just complicated. In principle, a bunch of clever experts can plan and predict a complicated project from start to finish without a single error. At least there exists some reasonable margin of error that you can prepare for and expect it to be enough. 

For this kind of project you don't need Scrum. You can have a fixed price, fixed scope and fixed schedule and then you just do it.

So why do so many "normal" projects fail and go over budget and over schedule and fall short of the planned scope and value then?

Maybe it's just hard to know if a project is just complicated or if it's in fact complex. So how can you try notice if a project is creeping towards being complex?

One pretty reliable sign of a complex project is that there is lots of people involved with it: lots of users, lots of requirements, lots of customers with rather unknowable preferences. Unless you are Hari Sheldon, predicting human behaviour is hard, if not impossible.

Just working with software can be a source of complexity. Software doesn't need to be large at all to be way beyond what a single person can understand and take into account. Once software starts to resemble a brain in it interconnectedness it becomes extremely hard to control things to perfection. Raising a child is obviously complex. The feedback loops are long and hard to identify. Is this person insecure because they didn't feel loved by their parents when they were a baby? Is this bug related to the thing that we coded three years ago?

Size can become a source of complexity. Large enough project has so many dependencies that even if the project is about moving rocks from one place to another, world politics or ships getting stuck in canals can cause unexpected and unpredictable cause and effect chains.

Hot take: I think the real reason why many projects get considered complicated instead of being handled as complex is just human hubris and fear. It's not hard to know, it's hard to admit. If we can't plan and predict this project, does it mean we are not clever experts? If we can't give a fixed price, will the customer not want to invest in the project? If we can't promise the customers will like our idea, do we get the funding to build the product?

Scrum is a way to embrace this uncertainty and maximise the chance of the shot actually hitting the mark. If you treat the situation as complex and use Scrum, you can try to be antifragile about the whole thing. You don't have to make impossible promises. You can still have fixed price, even! Just cut back on the posturing and presenting certainty and align yourself to take advantage of the surprises.

P.S. Is this actually related to living a life using Scrum? Not really. Just needed to get this off my chest.