Как мы трижды меняли формат «Ретро» и какие проблемы хотели решить

Очень многие недооценивают ретро, а ведь именно ретро позволяет внедрять гибкие методологии.

Без ретро, это не гибкая методология, а спринт-ориентированная. Какая же она гибкая, если один раз настроили и все? Методология должна адаптироваться к проекту по мере изменения/роста проекта.

И именно ретро и помогает вывести проблемы на передний план и найти решение. Если у участников ретро нет никаких полномочий на изменение процессов, то смысл в ретро отсутствует. Действительно задача менеджера организовать правильную работу ретро-митингов.

У нас примерно так было - каждый может вынести свои вопросы на ретро. Совместно тратим небольшое количество времени чтобы уточнить это системная проблема или разовая и ее можно решить прямо сейчас, если нет - вносим в бэклог ретро и назначаем ответственного, который до следующего ретро должен провести исследование и возможно предложить решение. Ответственный не обязательно то, кто будет внедрять решение. Это тот, кто отвечает за организацию, коммуникации, ищет кто и как может решить. На следующем митинге ответственный может и измениться, если будет понятно кто лучше это сделает.
Главное, что в бэклоге мы отслеживаем сколько времени проблема там висит, и если висит слишком долго, повышаем приоритет. Бывают проблемы, которые требуют значительных изменений в процессах. Надо обосновать что эти изменения окупятся.
И да, благодаря такой структуре было проведено множество как мелких, так и достаточно значимых изменений в работе проекта.