Wir nennen das Review. Es ist immer offen für alle in der Firma. Was das für Probleme sind würde mich schon interessieren. Chicken haben halt ihr Klappe zu halten ;-)
PPT gibts bei uns nicht. In einem Buch habe ich auch gelesen dass das verboten werden sollte. Gezeigt werden soll nur funktionierene Software. Nur das zählt und dafür zahlt der Kunde. Dafür sollten die Teammitglieder "echt viel Arbeit" stecken. LoD wird bei uns schon vorher gemacht.

Ja ja die Abkürzungen ... LoD = Level of Done. Was ist AC?
Und nicht nur Chicken, sondern auch Hasen haben die Klappe zu halten...

Was du am Ende der Review/Demo haben möchtest ist Feedback zu dem, was erledigt worden ist. Dabei sollte möglichst der da sein, der später mit dem Ergebnis arbeiten soll (beispielsweise ein Kunde oder Anwender). Ist der nicht da, braucht es einen engagierten und gut informierten Product Owner, der das aber nie ganz ersetzen kann. Zumindest sporadisch sollte das aber der Fall sein. Auch sollten das Ergebnis direkt "benutzt" werden können – bei Software sicher einfacher als in anderen Branchen, wenn auch nicht unmöglich.

Und was du vielleicht möchtest ist auch eine Reduktion von Risiko. Risiko in dem Sinne: Bauen wir das richtige? Wird das überhaupt funktionieren? Bei reinen Konzepten ist da natürlich Vorsicht geboten. Ein echtes Endergebnis (notfalls ein Prototyp) ist da besser. Denn sonst kommst du in die Lage, dass ein Konzept in der Praxis nicht tauglich ist.

Was für mich eine "gute" Retrospektive sonst noch ausmacht:

- Feste Timebox (die bekannte Empfehlung ist maximal 2h für einen 2-Wochen-Sprint)
- Eine Agenda (ggf. mit Teil-Timeboxen) und einen Scrum Master / Coach / Facilitator der die Gruppe geschickt durch das Meeting leitet
- Keine unfertigen Dinge zeigen (nach DoD), da es einen trügerischen Eindruck über den Gesamtfortschritt erzeugt. Das verstärkt das Bedürfnis, Dinge auch "fertig-fertig" zu machen. Und auch aushalten können, dass mal nichts da ist (so eine Negativ-Erfahrung kann wiederum als Hebel für das Entwicklungsteam verwendet werden)
- Vorbereitung minimal halten: Das was gezeigt wird, sollte schon das Arbeitsergebnis darstellen
- Visualisierung: Das, womit das Team auch schon selbst arbeitet (Sprint Board und Product Backlog als Whiteboard oder in einer Software). Muss somit auch nicht extra vorbereitet werden.
- Wertschätzender Umgang (das Bedarf ggf. Coaching derer, die das Ergebnis abnehmen)

Außerdem ist es immer gut, wenn der Product Owner schon während der Umsetzung eng mit dem Team zusammenarbeitet und in der Review/Demo gar nicht mehr vom Ergebnis überrascht wird. Da ist dann auch mehr Zeit und Energie, um sich um geänderte Anforderungen und die Prioritäten der nächsten 2-3 Sprints zu konzentrieren.

Wenn es in der Review viel um negatives geht, das lässt sich mit Tricks auflockern. Ein Bekannter hat mir einmal davon erzählt, dass in jeder Review ein goldener "Oscar" für das beste Feature/Ergebnis verliehen wurde. Damit lässt sich zumindest der Abschluss positiv gestalten und die Leute gehen mit einem anderen Gefühl raus.