I recently joined a company where retrospectives are part of the routine. They feel nonetheless sort of useless, since the issues do not get addressed afterwards. People bring up the same problems over and over again and there’s little to no progress on them. The main excuse is that there’s not enough time to work on those because of the ongoing project demands. I talked to a team member who has worked in the company for around 2 years and according to her, it has always been like this.
Are there any ways to influence positive change for me as a tester who is reasonably new in the team and not a manager?
In my experience being new or a manager has nothing to do with retrospectives making an impact. It’s about finding out things to change or try anew. Generally there’s a gap when each recorded action doesn’t have an owner who is responsible for it.
As an alternative you could always propose dropping the retro and see what the reaction is. Could be they actually see the value but are forced to other priorities so the only action should be finding time. Maybe by dropping a meeting or reducing frequency?
These are very general thoughts and may not apply in your situation but hopefully there’s something of use in there.
Sometimes it depends on the team - I’ve been on teams with passionate members who did everything they could to improve, but also on teams that just wanted to get the retro over with as quick as possible.
That said, a few potential ideas:
Focus on only 1-3 action items. Maybe 1 to start if things aren’t happening.
Create items on the backlog to be prioritized with all other work. Maybe split them up if the tasks are too big.
As @adystokes mentioned, tag someone to own each action item.
Try different types of retros - sometimes changing the prompts slightly can bring new life into a meeting that feels repetitive/routine.
Are there any ways to influence positive change for me as a tester who is reasonably new in the team and not a manager?
Make professional connections to people, get interested in what they do, why they do things in a certain way;
Learn a lot from everyone and everywhere you can, so that you become comfortable in many situations(personal, professional, business, domain, technology, system, relation, process…);
Show your worth by doing the best work as a tester (deep testing, rare bugs, hardly reproducible issues, analyzing and finding weird live system data, building interesting scripts/tools, finding bugs in code inspections or system design talks, debug or pinpoint the route cause of a problem, etc.); people will notice you by extraordinary things and appreciate it(should be ordinary things for a good tester);
Don’t think only for yourself or your profession; understand what others are going through; find ways in which you can support the team to do things faster, and be less stressed; talk directly to people or do things for them when you can;
Inspire calm and confidence; When people are under stress, you’re the last person they might want to hear complain or ask more of them. Find your moments and filter what things you want to share with them.
Learn about the history of the product, project, or people; this can reveal some debt in various areas that can be useful to understand the context; Use it to your advantage, foreseeing longer-term improvements based on small changes.
Don’t ask or wait too much for permission(like retro meetings), drive changes by yourself; be prepared to be alone on a subject for a longer time if others don’t see the benefit; review with a few people that you’re closer to if it’s a useful, or worthy thing to continue doing;
It can take months, even a year to gain their trust. But once you’re in, you have to keep the trust and build your influence based on it and by going to the next professional level.