As for trust and values, I might combine the two and say that members have to trust in each others values. For example, I don't want to bother to get my code reviewed by someone who doesn't care about its quality, and I don't want to put in the effort to review someone's code if they are only having it reviewed to satisfy the process. These differences in values can really suck the energy out of the process.
The Sprint Review sections were most beneficial, because we were all quick to say what we felt needed changing, and everyone was excited to try. If we did something radical, we could call a 1-week sprint instead, or plan the sprint that we could easily adjust it and start a new one if that method didn't work, just in case the new method ended up sucking.
The first month of it was weird, and eventually a few months in we were an extremely well-oiled machine running a system that was nothing like the original Scrum plan we followed, because we learned which parts worked best for us, and which didn't, and experimented with adding a few methods of our own to the system.
The rest of the company moved onto Agile/Scrum after seeing our small team, but I don't think the majority of them are handling it well at all. The process isn't adaptable, if devs speak up about things they don't like, the managers tell them to "trust the process" and give it time (BUT THE PROCESS IS ALL ABOUT CHANGING THE PROCESS AND NOT BLINDLY TRUSTING THE ORIGINAL PROCESS!!!), and many of them would rather not work in a management system that should adapt like that. I'll get asked for advice on why their daily standups aren't working, give feedback, "Well that would involve changing things, and we'd rather not do that..."
Really, they're just doing waterfall but with daily standups and a bi-weekly planning session which is mostly meaningless. Whatever, at least the team I'm on now is willing to play it the dynamic way (myself and another member of that original scrum team are in it), and we're enjoying it very much.