An incident retrospective gives a broader audience the experience of intense problem solving and an opportunity to contribute their own insight into how we think about a complex system. Perhaps we can mix in some practices drawn from meetings with similar goals?
How and Why to Hold “Blameless Retrospectives”. post 
See In & Out Demo for pairwise repetition.
See Pairing, Mobbing and Variants for technique.
We assume some sort of efficiency will be achieved if we assemble a group to sit quietly while the most informed among us explains. But when the knowing is elusive and the context vast then a sequence of small group conversations might surface more insight and find that insight better articulated than a traditional meeting.
We might be concerned that the discoveries will not be widely shared. Not to worry. Clear thinking can spread as fast as any gossip. When our goal is to maintain effective models as much as shared models then we should go for effective models first.
We've identified the build and release of attention when programming which we've called "Episodes". Incident response follows a steeper build and possibly a longer tail. We see value in assembling the right people in the post-incident calm but feel we can push more of the norming into the long tail where episodes live.
We'd like to see this wiki develop as a place to do incident related work, to be refactored after each incident surprise teaches its lessons. See Recreational Measurement