I've been at a company that really decided to go all in on Agile and actually let teams change things to work more efficiently, and it's one of the best experiences I've had, it really had all the components that make things work.
One issue I've seen since then regarding retros is that they'll fall into two extremes. The rare one is that retros are just fun recess times that nobody gets anything out of besides doing doodles and ice breakers. The other one is that teams will try and be very action oriented and find concrete solutions to concrete problems, but will not have the emotional maturity to address difficult topics, so they're either avoid them or turn into screaming matches.
You need to feel somewhat close to your coworkers to be able to bring difficult topics with the certainty that others will know you do it for the right reasons and that you're all trying to work towards the same goal of making work more effective, pleasant and satisfying. Teams that never work on the closeness of their members cannot address important issues. You need the doodles, the inside jokes, the team spirit to be able to do that.
But you also need to have a mastermind to spot issues and then figure out ways to role play and brainstorm around those in a way that feels like playing, but ends up providing the team with actionnable solutions.
At the company i've worked at, I've had to sometimes do tasks that were really not my duties (data entry, QA work) because it was the most important thing that I could do for the team. I happily did it because I felt like it really was our project, that I'd be bringing value to customers and the company in doing it, and that our product would be better with that work done by me. I'd stay late if there was a problem I could possibly assist my coworkers with, even if I stayed for nothing or could only contribute through naive questions to try and get neurons firing... But we were a close team, despite having different roles and seniority levels, and we were all very happy to do what the project needed.
In my current company the sense of ownership isn't as important, people don't know each other as well (the team also is larger and with more turnover) so it's made of smaller groups of kinda close people.
In a perfect world everyone in all teams would be a trustable high performing dev and there would be no need for any lubricant to make the machine work smoother, but the reality is that the majority of us have pet peeves, quirks and shortcomings, the group can be a good way to mitigate those, as much as processes and methodologies, but having both is what will get you the best results, and I think this is something that is overlooked by many teams.