"повышение эффективности процессов внутри команды за счёт обсуждения результатов работы команды и происходящих в ней процессов."

это ровно то, что писал Игорь выше "БУДЕТ ЕЩЕ ЛУЧШЕ"

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

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

Вот тебе сценарии.
1) Почему не успели сделать запланированный скоуп
2) Анализ метрик по багам: почему баги на проде
3) Почему тестирование остает
и т.д.

Если команда непрерывно работает с ретро, то у нее наверняка есть change log  с тем, над чем они работают и что они могут анализировать и оценивать на ретро для формирования плана с дальнейшими действиями.

ооценка работы команды в сспринте — хрень каая-то. ценность в чем?

почему не успели сделать? потому что планировали хреново.
уберите скрам, начните планировать нормально :)

набросил и ушел. Работа. Настя, посмотри мой видос пожалуйста тоже

ретроспектива по провалам командного планирования очевидно должна быть командной.

было бы планирование индивидуальным — не было бы нужды отрывать людей.

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

ни для планирования, ни для ретроспективы почему не срослось

не всегда проблема в планировании)

и ретроспектива помогает посмотреть системно на все проблемы

я не о том немного. раз инициировали спринт всей командой, очевидно. что ретроспектива нужна всекомандная

я просто пытался подвести еще раз к тому, что если бы не было этого нафиг на мой взяглд ненужного командонго планирования, то не надо было бы и команду всю от работы отрывать на ретросективу

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

и вот если ретро — для улучшения процесса только, а не для рефлексии о том, почему ну успели, то я заявляю, что ретро не нужна

а продолжим после моего видео, хорошо?

Ок

спасибо, Игорь!

Я в том числе работаю с командами, где нет планирования) но при этом есть ретроспективы, регулярные.
И это лучшее что случалось с командами.
Пример:
до ретроспективы команда правила баги по 60 дней, потому что у них было оооочень много итераций с возвратами в требования и разработку из-за багов или хреновых требований.
И вроде как менеджеры это осознавали и декларировали изменения и пытались убедить команду работать с ними.
Но все со временем забивалось.
Потому как команда не осознавала проблему.

И только с помощью ретроспективы мы смогли вытащить все проблемы наружу, и достучаться до осознанности людей, что с этим что-то надо делать.

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

> Я в том числе работаю с канбан командами, где нет планирования) но при этом есть ретроспективы, регулярные.

это те что используют скрам-доску но без стэндапов? 🙂