If you are going to roll-your-own solution, start with retro and build from there. Retro is the most important part of the process. There's a reason it's the only explicit activity mentioned in the manifesto. As long as you keep reflecting on past performance and continually try to improve you'll probably end up with a good process.

It encourages everyone to ignore/bottle up issues until the magical retro day where everyone can spend a couple of hours venting their frustration. At which point nothing gets done and the process repeats. Project issues should be resolved immediately, directly with the people responsible and with actionable outcomes. Not during a glorified weekly/fortnightly 'meeting'.

If that's what happening then the retros are being terribly run. Especially if you're not coming away with an actionable outcome.

If you can deal with it immediately - you deal with it immediately. Nothing in any agile process says you should save it up for the retro. Many quite forcefully say the opposite.

The retro is for helping you spot larger scale issues or systematic problems that you miss / don't have the room to address in the day-to-day project.

(For example, we ran one last Friday where it was pointed that I'd been a bottleneck on several different tasks. I'd not been bright enough to spot that myself. Since the bottlenecks were with different folk nobody had spotted it at the time. Bring everybody together and - boom - problem identified and some options for solutions spotted. No angst or venting involved. There was cake though ;-)

That's what I mean by retro. Two parts: self-reflection, and change of behavior.

Sounds like your problem with retro is that behavior isn't changing. Maybe it's management stopping things from changing, or teammates who refuse to go along with what the team wants. A team that won't change won't get better.