The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship.
Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.
Retros all too often focus on the last thing that happened and risk turning into a complaint session.
I've told my team anyone is welcome to ask for a retro whenever for any reason, but we don't make them recurring meetings because there is too much of a temptation to find something wrong to fill the time.
Best retro I ever had, on a small team of seniors: we all sat down, looked at each other, agreed that a sprint happened and we couldn't think of anything that was good or bad about it. Then we called in our manager, who also acted as scrum master, so we could do planning for our next sprint. I thought this was reasonable enough - ostensibly we'd do retro and then planning back to back, and none of us minded the chance to take a few minutes and reflect if we had anything we should discuss.
By contrast, I've worked with scrum masters who were strict about the process and insisted _every_ retro needed to have at least one improvmenet or action item out of it, preferably more. I found this pointless and I've rarely seen them actually followed up on.
This is exactly why I hate retros. It's just a venting session. We're going to whine about some things, of which we have absolutely no power to change, and somehow that changes the future.
But people seem to love them.
I'd prefer to spend that time putting my head down and grinding through whatever sucky thing people were otherwise whining about.
As a developer, I find retros most useful when EMs (and probably PMs, depends on how things are configured organizationally) aren't present, as it should give a chance to talk freely about challenges you or the team face, which often are organizational in nature and may involve one's management chain. My current role doesn't adhere to this, and it makes retro often really painful.
I would agree with you. I never want my manager there. As an EM, I never want to be there. And yet, as the years go by, when I have an EM role I find my presence is requested. Again, who knew?
I don't know, at least for my current team a lot of the stuff we complain about in the retro is beyond the team level: coordination between teams, infrastructure issues, ... The intra team issues are usually talked about before (e.g. during standup, or just asynchronously).
If the EM is not there, those are not actionable. What we try to do is: do the retro by ourselves, and invite the EM at the end of there is stuff for them. Usually they are not available though...
The only thing on that list I've ever liked is the velocity charts. And the only reason I liked them is that it helped me give a slightly less made up date to my own bosses to explain when something might ship.
Over the years I've found that devs have been the one who like retros. Or at least a certain subset of them. When I've been an EM I would try to get rid of them, only to have them requested by my teams. Who knew.