I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at.

I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. 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.