One of the things that often makes retros ineffective is that technical issues are not discussed. Programmers are technical — by nature, and in the work they do. They want to improve their technical pipeline. If that doesn’t get discussed in a retro, they lose interest. Programmers are not touchy-feely in general: they prefer to talk about concrete things.

One thing that helps is to have technical metrics — things such as cycle time, production defect rate, code quality, test coverage, etc. Those kinds of metrics give you a basis for starting technical discussions. Also, the person facilitating needs to be insightful to ask the right questions — they need to understand the technical work. Then they will be able to challenge the team by say, e.g., “So the feature cycle time is four weeks — what is keeping it at that?” to which the team might say, “We can’t shorten it because everything is as tight as it can be”; and at that point most SMs will say “Okay”, but a SM who understands the work will say, “Well, we are currently waiting for integration testing to occur — can we shift some of that left?” In other words, if the SM knows what improvements might look like, they can ask the right things. That’s when a retro gets interesting.