Retro efficiency, how not to miss the important?
Do you feel after retro that there are problems that have not been identified? What are you doing to identify hidden problems, when people make poor contact? What techniques/tools/measures do you use? How do you track the results of retrospectives (any team metrics, KPIs, etc), action lists performing?
Many thanks,
@Veronica Yudina, In complex enviroments it is quite possible that you may not be able to identify all the problems at a retrospective. The best advice would be to bring transparency over what exists and inspect and adapt. Also, you do not need to wait till the retrospective to implement an improvement or to try something different. The retrospective is just a formal opportunity to ensure that this happens.
I would be careful with how KPIs and metrics are used as these could be gamified.
Do you feel after retro that there are problems that have not been identified?
Why not identify problems throughout the Sprint, in as timely a manner as possible?
There will always be hidden problems of varying degrees. Just like there will always be bugs released to production. So focus on the problems that are identified because those the ones causing the most issue. You do not need to address every problem, just some of them. Pick some that are causing the most pain for the team and experiment on how to address them.
And as stated above, address problems when they are recognized. If the team is pained by an issue, fix it. If you broke your arm today, you wouldn't wait 2 weeks to see a doctor and have it set. You'd do it as soon as you can.