At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete.
Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'.
I think the biggest factors we had in our favour were:
1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us.
2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones.
3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary.
I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
#1 was clustering similar sad faces.
#2 was as a team, agreeing on actions we could take on those clusters.
#3 was tracking how well we did on performing those actions.
If it's just venting, it's not overly useful.
In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.