Ретроспектива по шагам. Рецепт
Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, «обучающих» материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.
Кто присутствует
Ретроспектива это в первую очередь мероприятие, направленное внутрь команды. Его решения — это решения для самой команды, и вырабатываться они должны внутри. Вполне допустимо на ретроспективу принести те самые две пиццы, использовать нецензурные выражения (но не друг на друга!), принести куклу большого начальника и/или заказчика. Важно, чтобы каждый член команды чувствовал, что он может высказать своё мнение, и это не то что не приведёт к какому-нибудь негативу, а ровно наоборот — будет использовано для пользы команде.
Поэтому на ретроспективе должны быть, с одной стороны, все члены команды, с другой — никаких больших начальников, секретарей, представителей заказчика и соседних команд. Ретроспектива — это не отчёт! Это не презентация! Это не спектакль, который команда играет для заказчика (в отличие от обзора спринта). Это внутреннее мероприятие команды, которое, в принципе, иногда можно даже заменять тим-билдингом. И возможно от этого даже будет больше пользы, чем от ретро.
Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в «не туда», и по его итогам даже не понятно, а почему и как это исправить.
В будущем проведение (фасилитацию) ретро можно передать члену команды, а через некоторое время выбирать нового фасилитатора для каждого нового ретро.
Когда
Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. «Сила» методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.
Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.
Что нужно для ретро?
Если ретро проводится в «реальном мире», потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.
В «виртуальном» мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать «плюсы», «минусы» и «действия».
Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.
Будучи хорошим начальником (или планируя им стать) — принесите на ретро орешков, конфет, печенек (*закадровое узнаваемое дыхание*), запланируйте общий ланч с пиццей без отрыва от «производства».
Начало ретро
В начале всем участникам команды раздаётся задание. Нужно придумать и записать (пока что в тайне от других членов команды — это важно):
(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.
(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.
Не нужно пытаться «оптимизировать» процесс и просить членов команды записать эти пункты заранее в качестве домашнего задания. Всё равно им придётся на это тратить время, верно? Пусть лучше потратят его все сразу в одном месте, не мучаясь угрызениями совести за несделанную домашнюю работу и без смущающих взглядов коллег, которые были такими замечательными, что сделали заранее (читай — за 5 минут до встречи, отвлекаясь от какой-нибудь скучной еженедельной встречи).
Сначала про «плюсы». Этот пункт важен, хотя бы для закрепления того, что команда сделала хорошо. Похвалить самих себя — тоже важно. Наверное это подтвердит любой психолог. Граница снизу здесь нужна, чтобы каждый член команды заставил себя, во-первых, вспомнить прошедший спринт, а, во-вторых, включился таким образом в ретроспективу. «Не хотим терять» — это важная подсказка. Например она сразу отекает такие вещи, которые не зависят от команды. Нет смысла обсуждать возможность удалённой работы, если не команда решает этот вопрос. Или есть смысл упомянуть, как нравится текущий CI и быстрое прохождение ревью, ведь именно от команды (обычно) он и зависит.
Другое важное назначение «+»-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point’ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.
Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от «проблемы +1», когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает «слепое» покер-планирование).
Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).
Вполне можно и допустимо сюда писать что-то, что на первый взгляд кажется «внешним» по отношению к команде. Потому что потом на детальном разборе может оказаться, что при внешней причине мы можем что-то поправить в процессе внутри команды.
Анализ
Начинаем с плюсов. Тут можно просто выписать их в первую колонку (наклеить стикеры), при возможности сгруппировав их для удобства наблюдения и красивого представления вышестоящему начальству. Просто пока помните, что эти плюсы — это что ваша команда хочет сохранить хотя бы на следующий спринт и не потерять при выполнении action point’ов.
Минусы. Самый сложный этап. Игра в доктора «наоборот».
Берём каждый стикер (присланный нам в персональные предложения пункт) и. не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И «лечение» самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.
Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point’а). Например. Член команды записывает на стикере «у нас неоптимальный CI-скрипт«. Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?
Уточняем у члена команды, «[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален»? Внезапно оказывается, что:
- скрипт медленно работает
- медленная работа приводит к медленному прохождению pull request’ов
- невозможность распарраллелить работу приводит к простою
- это приводит к медленной работе члена команды
- это приводит к необходимости ручного перезапуска CI
- это приводит к медленной работе члена команды
На каком шаге остановиться — сказать сложно. Но в любом случае каждый следующий шаг описывает более общую проблему. В целом все пункты так или иначе сводятся к одному конкретному — «замедление работы команды». Поэтому тут важно остановиться где-то за 1-2 пункта до этого.
Но зато для каждого следующего более общего уровня можно предложить самые разные варианты решения проблем:
- поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно
- поставить посильнее машину для CI
- выкинуть часть действий из CI-скрипта, не переписывая его кардинально
- полностью переписать CI-скрипт
- научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI
- сделать простой скрипт для перезапуска failed-сценариев 2-3 раза
Но пока что возможный список даже не озвучиваем. Но мы должны (из своего опыта) как-то понять, что именно та формулировка, которая будет записана, может, хотя бы в теории, быть решена несколькими разными способами. И вот именно эту формулировку и надо записать в «минусы».
Кроме того, более обще записанная формулировка имеет больше шансов пересечься с «минусом» от другого участника. А это хорошо — значит у нас не 30 разных проблем, а, скажем, 7-10 (сгруппированных). К этому и надо стремиться.
Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, «нет, это вовсе не то, что меня беспокоит, меня беспокоит другое». Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.
Голосование
Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных «минусов» было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их «минусы»).
В результате формируется отсортированный «по голосам» список проблем.
Блиц-этап
На данном этапе включаем секундомер и предлагаем по 60 секунд на решение каждой проблемы, кроме Top3 (в любом порядке). В рамках этих 60 секунд можно предложить «быстрое» решение проблемы. Не важно, насколько сильно оно решает проблему, главное, чтобы хоть как-то решало. Если никто из членов команды не против предложенного решения, оно записывается в action point’ы. Если против — решение сразу же откидывается без обсуждения (время на обсуждение не тратится).
60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.
Перерыв на кофе
Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/
выпить/отойти проверить почту.Обсуждение. Action Points
Итак, у нас есть top3 проблем. Самые больные, самые серьёзные, самые мешающие команде. На каждую проблему хоть час обсуждения (поэтому ретро и занимает от 3-х часов). Как придумать возможные решения — не знаю. Однако, знаю, что делать с возможными решениями.
Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?
Во-вторых, решения должны проходить валидацию у тех, чьи проблемы были изначально сгруппированы в единый «пункт симптомов болезни». Хотя бы один из них должен подтвердить, что предложенное решение действительно сделает его жизнь проще.
В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.
Плохой вариант
Вариант получше
Нужно устроить встречу и обсудить розовых единорогов
[Олег] устраивает встречу во-вторник в 15 часов по обсуждению проблемы питания розовых единорогов
Ответственно подходить к ревью pull request’ов
— (или) при отклонении pull request’а оставлять комментарий
— (или) настроить бота, назначающего PR на ревью на членов команды
— (или) добавить в CI-скрипт автоматический линтер, а все проблемы в оформлении, которые им не покрываются не считать проблемамизаранее формулировать тикеты в jira до планирования
[Олег] заведёт в outlook еженедельный backlog grooming до планирования с участием владельца backlog’а, представителя аналитиков и solution-архитекторов смежных систем
Полученные шаги записываются в action point’ы.
Почему ретро может не помочь
Может так случиться, что сделали всё по рецепту, а огонёк в глазах команды всё тусклее и тусклее, а производительность команды падает.
Потому что автор этого текста ни хрена не знает.Ретроспектива в этом случае позволяет найти часть этих причин, и задуматься, почему эти причины до сих пор не исправлены.Признаками проблем являются:
- Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды «как у нас всё хорошо, как здорово и дружно мы живём,
дорогой дедушка Ленин«. Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро. - Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point’ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!
- Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы». Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.
- Невыполненные action point’ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.
Самой большой проблемой является понять, что у
насвас проблемы. Вы можете спокойно смотреть на красивые отчёты о ретроспективах в confluence, показывать начальству, а члены команды почему-то не хотят на них ходить. Моя рекомендация — приглашайте на ретро раз в полгода кого-то со стороны. Не начальника, а методолога, коллегу из параллельной (или далёкой) команды. Возможно пригласить даже его сразу как фасилитатора — попробуйте формат ретроспективы от другой команды. Пусть её проведёт тот, кто не привык к вашему формату.- scrum
- agile
- ретроспектива
- управление проектами и командой
- Управление проектами
- Agile
- Управление продуктом
Структура идеальной ретроспективы
Привет! Меня зовут Катя Чернышева, я Group head в AGIMA. По работе мне приходится часто проводить ретроспективы — встречи с командой, на которых мы анализируем, что хорошо в нашем рабочем процессе, а что можно улучшить. Еще чаще я рассказываю о том, как их проводить, начинающим коллегам.
Главный вопрос, с которым они ко мне приходят:
— Как сделать ретроспективу одновременно полезной и интересной?
Я тоже долго искала на него ответ, но в итоге пришла к простому выводу: я против скучных встреч .
Каждая встреча должна быть наполнена смыслом, и вся команда должна этот смысл понимать. А еще важнее, чтобы встреча была динамичной и яркой. В этой статье расскажу, как сделать ретроспективу как раз такой. Уверена, полезно будет и тем, кто уже давно руководит проектами, и тем, кто делает первые шаги в этом деле.
Что такое ретроспектива
Ретроспектива — это регулярная встреча, на которой команда обсуждает рабочий процесс и при необходимости что-то в нем меняет. Ретроспектива входит в список регулярных мероприятий почти всех гибких методологий.
Цель ретроспективы — запланировать повышение качества и эффективности, снизить напряжение в команде, подсветить позитивные моменты в работе. В общем, провести рефлексию — понять, какие процессы работают хорошо, а какие нет.
Задача руководителя проекта — подготовиться к ретроспективе, провести ее и затем проследить, чтобы все договоренности исполнялись.
Подготовка к ретро состоит из 4 шагов:
- Запланировать время команды.
- Выявить проблемы, которые нужно рассмотреть.
- Придумать тему.
- Продумать тайминги.
Про каждый шаг расскажу отдельно.
✔ Планируем время
Ретроспектива должна проходить в такое время, когда удобно прийти всем. Если придет меньше половины команды, то принятые там решения просто не будут иметь достаточно веса.
Если в команде 10 человек, но у двоих отпуск, у одного больничный, а еще у двоих встречи, ретроспективу лучше перенести. В идеале на ретроспективу должны приходить все. Команда должна понимать, что это необходимое и обязательное мероприятие. Пропускать его не стоит.
Под ретро необходимо завести встречу в календаре, чтобы добавить туда всю команду. Тогда каждый будет заранее знать, что у него запланировано и не поставит на это время ничего более важного. Но даже если все подтвердили участие через календарь, можно заранее напомнить о ретроспективе в общем чате.
Плохая практика — отменять ретроспективу минуту в минуту, как и любую другую встречу. Иногда случается, что приходит только часть команды, потому что у остальных внешние встречи или горящие дедлайны. Тут ничего не поделаешь — встречу проводить бессмысленно. Но в этом случае все, кто не смог прийти, должны подтвердить участие в следующей ретроспективе.
Важно, чтобы такая ситуация больше не повторялась. Можно проводить голосование примерно за неделю до ретроспективы, чтобы выяснить, кто сможет присутствовать. Тогда у вас будет возможность заранее принять решение о сдвиге сроков, не день в день.
✔ Выявляем проблемы
На этапе подготовки нам нужно понять, какие темы в команде «наболели». Речь на ретроспективе идет об острых проблемах, которые мешают команде работать.
Например, команда медленно выпускает в прод обновления для iOS. Это вызывает недовольство заказчика, конфликты. Конечно, всем это не нравится. Значит, нужно найти корень проблемы, а затем и ее решение. Под проблемой мы всегда понимаем что-то, что имеет прямое отношение к процессу производства.
Важно, что проблема не может заключаться в одном человеке, в нескольких людях или во всей команде. Проблема всегда связана с процессом, а люди — это не проблема. Об этом нужно напоминать команде.
Если всем кажется, что веб-разработчик плохо работает, то вопрос следует поставить иначе. Почему он плохо работает? Ему не хватает компетенций? Его достижений не замечают? Плохой разработчик — это не проблема всего проекта. Он один не может сломать весь проект. Это проблема процесса, управления или подбора кадров.
На этом этапе нужно подумать, как раскрыть проблемы с помощью команды. С одной стороны, если ретроспектива проходит не в первый раз, проблемы могут быть уже понятны. Но с другой, было бы неплохо периодически проверять, все ли смотрят на вещи одинаково. Возможно, кто-то заметил проблему там, куда никто до него не смотрел.
Узнать, какие проблемы замечает команда, можно разными способами. Например, можно попросить сообщать о таких проблемах вам в личку. Еще члены команды могут записывать в Miro проблемы, которые появляются в процессе работы между ретроспективами. Также можно запустить голосование в чате по проблемным зонам.
Для каждой ретроспективы мы выбираем один самый острый вопрос.
✔ Выбираем тему ретроспективы
Ретроспективу можно проводить и без темы, но, скорее всего, в этом случае она будет безликой и скучной. Поэтому тему желательно выбрать — это расслабит команду, создаст комфортную атмосферу.
Например, у меня темой ретроспективы часто становятся вселенная Гарри Поттера, «Пиратов Карибского моря» или Marvel. В качестве темы лучше выбирать фильмы, книги, сериалы или игры, которые все знают. Наверняка в вашей команде есть точки, в которых пересекаются интересы если не всех, то хотя бы большинства участников.
Между командой и ее проблемами нужно найти связующие элементы, а затем встроить их в новый мир. Это сделает рефлексию не только полезной, но и интересной, вовлечет команду в процесс. А еще тема поможет визуализировать доску.
Например, однажды мы фиксировали плюсы и минусы на доске в стиле Гарри Поттера. Плюсы отправлялись в Гриффиндор, минусы — в Слизерин.
✔ Продумываем тайминги
Каждый этап ретроспективы необходимо спланировать заранее. Нужно понимать не только, что конкретно будет делать команда, но и сколько займет каждый этап. Иначе встреча может длиться вечность. Тут опишу, какого тайминга обычно придерживаюсь.
1. Командный радар ~ 8 минут.
2–3 минуты на сам радар и около 5 — на его разбор. Ниже я расскажу о радаре и его назначении подробнее.
2. Проблемы команды ~ 30 минут.
Выявляем проблемы на этапе подготовки к ретро. Но раскрыть их важно на самой встрече. Тут проблему нужно сформулировать и попросить команду найти решение. На этом же этапе мы генерируем идеи.
Например, у вас есть проблема: никто не выступает в группе, хотя вам важно делиться опытом внутри отдела. Предположим, сама команда не очень большая — 5 человек. В этом случае можно выписать сильные стороны каждого. Предложить всем проголосовать. Так мы выберем основную сильную сторону каждого человека. Кто-то хорош в общении с заказчиком, а кто-то круто ведет ретро. Теперь каждый должен выступить с докладом о своей суперсиле.
3. Анализ отчетного периода ~ 1 час.
Это классический блок — доска с плюсами и минусами. Фиксируем, что хорошего и что плохого произошло. Заодно решаем, как сохранить хорошее и как не допускать плохого впредь. По итогам этого блока делаем Action-план — план по усовершенствованию процессов.
Например, мы всей командой не понимаем, где и какие документы лежат. Кто-то вынес это в минусы, остальные подтвердили. Сообща решили, что нужно разобраться в документах, разложить всё по полкам и папкам, все папки подписать. Фиксируем это решение в Action-плане и выбираем ответственного.
Золотой правило №1. Чем реже ретроспектива, тем она дольше.
За большой период у команды накопится достаточно напряжения, проблем и тем, которые стоит обсудить. А значит, и времени на ретро уйдет больше. Поэтому ретро не стоит пропускать. Проводить его нужно так часто, как требуется.
Понять периодичность просто: сначала проводите ретроспективу раз в полтора месяца. Первая будет долгой — это нормально. Но посмотрите, как долго будет длиться вторая или третья. Если уложитесь в полтора часа, можно ставить встречу реже — например, раз в 2 месяца. Если не уложитесь в 2–3 часа, стоит проводить чаще — раз в 2 недели или в месяц.
Если время на встречу истекло, а карточки еще остались, то просто запланируйте вторую встречу. Пропускать и забивать на чьи-то карточки нельзя.
Ретроспектива по итогам года проходила в стиле церемонии вручения «Оскар».
✔ Готовим доску для ретроспективы
Доска должна быть готова заранее. Оформить ее важно аккуратно и грамотно, чтобы ничто не отвлекало команду. Все блоки должны быть разумными и логичными, должны соответствовать вашему плану. Не стоит добавлять поля, которые вы не успеете заполнить.
То есть если у меня по плану сначала идет командный радар, потом обсуждение проблем, потом плюсы-минусы и Action-план, то соответствующие поля на доске должны идти в той же последовательности.
Желательно проводить все ретроспективы на одном поле. Так вы можете всегда обратиться к прошлым ретроспективам, посмотреть Action-план и старые карточки. Если какая-то карточка кочует из одной ретроспективы в другую, то проблеме явно нужно уделить больше внимания.
Miro — это наиболее удобный инструмент для ретроспективы. Но обратите внимание: этот сервис сейчас нельзя оплатить российской картой.
✔ Проводим ретроспективу
Доска готова, тайминги отмечены, люди в сборе. Пора начинать.
В первую очередь проводим командный радар или что-то наподобие. Так мы снимаем напряжение и понимаем, что беспокоит команду.
Это шкала, на которой каждый участник команды отмечает, насколько ему комфортно работать. Обычно я спрашиваю о 3 вещах: насколько клевые люди работают на проекте, чувствуется ли в команде поддержка и нравится ли проект в целом. Каждый берет точку нужного цвета и располагает на шкале, как чувствует. Выглядит это так:
Командный радар помогает быстро понять общий эмоциональный фон команды.
Затем мы переходим к блоку, посвященному той самой проблеме, которую выявили заранее. Ищем ее решение и обсуждаем, как будем исправлять ситуацию. Примеры я приводила выше.
Дальше приступаем к блоку плюсов-минусов. Здесь мы говорим не только о плохом, но и о хорошем. Не бывает, что плохо всё — нужно находить поводы похвалить себя и друг друга.
Проведение ретроспективы — это деликатный процесс. Тут нужно быть немного психологом, немного модератором. Важно услышать всех, дать понять, что их мысли поняты, ни с кем не спорить. Нельзя сказать кому-то из команды, что его идеи так себе. Больше того, нельзя допускать, чтобы кто-то другой так говорил. Пусть люди высказываются. Это их время.
Золотой правило №2. Всегда ставьте ответственных за задачи, которые вы берете в работу.
По итогам ретроспективы составлен Action-план. Обязательно нужно понять, кто будет отвечать за каждый его пункт. Сначала спрашиваем, есть ли желающие. Если нет, то назначаем ответственного сами.
Золотое правило №3. Нельзя никого критиковать: каждая идея имеет право на существование.
Вот так может выглядеть Action-план — тут мы назначаем ответственного по каждому вопросу.
✔ Выполняем Action-план
Про этот пункт часто забывают, хотя во многом ретроспектива проводится именно ради Action-плана. Фактически Action-план — это митинг-репорт. После встречи мы пишем всем письмо, в котором напоминаем, какие задачи взяли в работу. Убеждаемся, что все понимают свои задачи и готовы над ними работать. Также Action-план можно закрепить в чате или занести в общую базу знаний.
Про выполнение задач из Action-плана нужно напоминать. Это может всех раздражать, но что делать? Если Action-план не будет выполняться, то ретроспектива будет чем-то вроде сеанса у психолога. А она должна менять производственный процесс к лучшему.
Чтобы задачи выполнялись, они должны быть разумными. Например, у команды проблема: не хватает Камерон Диаз в офисе. В Action-план я внесу следующее: пригласить Камерон Диаз. Написать я ей могу, но вряд ли она приедет. Значит, эта задача обречена, добавлять ее в план не стоит. Если вы берете в работу невыполнимые задачи, они висят мертвым грузом и всех бесят.
Ретроспектива — это мощный инструмент, который может закрыть несколько задач: сплотить команду, решить проблемы, улучшить процессы и взаимоотношение в команде. Поэтому пренебрегать этим форматом не стоит. Наоборот, чем интереснее вы его сделаете, тем больше пользы он принесет.
Рассказывайте в комментариях, как вы проводите ретроспективу. А если у вас остались вопросы, задавайте — помогу разобраться.
P. S. Мой коллега Дима Курамшин ведет телеграм-канал об управлении проектами. Там много полезной теории и примеров из практики — присоединяйтесь.
Комментарии и обсуждения статьи на vc.
Ретроспектива в Scrum �� — как проводить и зачем вообще нужна ретроспектива в Scrum
Ретроспектива спринта в Scrum (или просто «ретро») — это важное мероприятие, от реализации которого зависит развитие команды и эффективность процессов в команде.
Редактировать
Что такое ретроспектива в Скраме
Ретроспектива — это мероприятие (или «церемония»), направленное на улучшение командных процессов за счет обсуждение предыдущих событий и процессов в команде, которые наблюдались в течение спринта.
Редактировать
Founder, Executive Partner
Зачем нужна ретроспектива
Ретроспектива — это «возможность для Скрам–команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем Спринте». Если этим пренебречь — вы можете не заметить, если в команде происходят деструктивные процессы, которые мешают работе.
Редактировать
Founder, Executive Partner
Как проходит ретроспектива
За процесс ретроспективы отвечает Скрам–мастер. Ключевой принцип ретроспективы заключается в том, что мы по–человечески относимся к любым косякам и ошибкам, при этом обращаем на них внимание.
Редактировать
Founder, Executive Partner
Что такое ретроспектива в Скраме (v2)
Ретроспектива — это мероприятие (или «церемония»), направленное на улучшение командных процессов за счет обсуждение предыдущих событий и процессов в команде, которые наблюдались в течение спринта.
Это мероприятие, которое завершает спринт. Прямой целью ретроспективы является повышение эффективности процессов внутри команды за счет обсуждения результатов работы команды и происходящих в ней процессов.
В результате ретроспективы команда может принять новые решения о том, как можно работать лучше и делать больше результата.
Редактировать
Founder, Executive Partner
Переквалификация в IT
Станьте руководителем Digital–продукта в Enterprise
Начать обучение →
Зачем нужна ретроспектива (v2)
Согласно Scrum Guide, ретроспектива — это «возможность для Скрам–команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем Спринте».
Напомню, что прозрачность, инспекция, адаптация — это «три кита» Скрама. Это основы, на которых базируется этот фреймворк. Это основа ценностей Скрама.
Это значит, что если вы не делаете ретроспективу, или делаете ее недостаточно качественно — вы рискуете разрушить основу Скрама — инспекцию. В результате вы можете начать получать плохие результаты от командной работы.
Инспекция необходима, чтобы быть в контакте с реальностью и изменениями, которые происходят в мире. Инспекция, направленная на саму команду — это возможность улучшить командные процессы, отследить дисфункции, найти новые способы и инструменты работы.
Если этим пренебречь — вы можете не заметить, если в команде происходят деструктивные процессы, которые мешают работе. Это обязательно проявится в итоговых результатах командной работы.
Именно поэтому нужна ретроспектива.
Редактировать
Как проходит ретроспектива (v2)
За процесс ретроспективы отвечает Скрам–мастер. Именно он следит за качеством процесса работы («как» делается работа, насколько процесс работы эффективен).
Для Agile–подхода к работе характерна фокусировка на человеческие отношения. В связи с этим ключевой принцип ретроспективы заключается в том, что мы по–человечески относимся к любым косякам и ошибкам, при этом обращаем на них внимание.
Для более «классических» форм менеджмента привычными являются такие мероприятия, как оценка, осуждение, порицание, санкции, и даже угрозы. Это все неприемлемо, если мы реализуем agile: ведь «Люди и взаимодействие важнее процессов и инструментов».
Именно поэтому качественная ретроспектива требует специализированных навыков, и очень редко можно наблюдать эффективную ретроспективу, которая модерируется человеком, который не специализируется на модерации таких мероприятий (при этом этот человек может обладать потрясающей экспертностью в своей сфере деятельности).
Ретроспектива может проходить гибко, в зависимости от потребностей и задач команды. Тем не менее, как правило каждому члену команды предлагается ответить как минимум на три вопроса:
- Что нужно начать делать? (Start)
- Что нужно продолжить делать? (Keep)
- Что нужно прекратить делать? (Stop)
В этим вопросам можно добавить «вариации»:
- Что нужно делать больше? (More)
- Что нужно делать меньше? (Less)
Фиксировать итоговые решения можно либо просто вербально (на уровне словесной договоренности), либо можно сделать на отдельной доске / флипчарте. Последний вариант обычно более предпочтителен, так как вы делаете ваши договоренности (commitment) визуализированными и прозрачными.
Так ваша команда будет помнить, о чем вы договорились и каких ориентиров следует придерживаться.
Цель этих вопросов — сфокусировать команду на обсуждение происходящих в команде процессов и улучшить их при необходимости. Это своего рода мозговой штурм, направленный на улучшение командных процессов.
Вопрос «Что нужно начать делать?» имеет своей целью внедрение новых полезных особенностей командной работы.
Ситуация постоянно изменяется, как и тип работы, который выполняется в конкретный момент. Возможно, для новой работы или для работы в новых условиях вам нужны совершенно новые способы взаимодействия — между командой, с клиентами, стейкхолдерами и т.д.
Вопрос «Что нужно продолжить делать?» направлен на выявление хорошо работающих моделей. Это повод для команды зафиксировать, что уже работает хорошо, и каких стандартов работы следует придерживаться.
Если не отвечать на этот вопрос, то вы можете по какой–то причине забросить полезные практики. Это скажется негативно на результативности команды, и придется потратить некоторое время, чтобы обнаружить, почему это произошло. Вам нужно понимать, что вы делаете хорошо, а не только то, что нужно улучшить.
Вопрос «Что нужно прекратить делать?» — очень важный. Он направлен на выявление всего того, что не ведет к ценности и к командному результату.
Это очень важно, потому что — как это ни странно — команды и люди в целом всегда склонны делать не только то, что полезно, но и то, что не является полезным. С точки зрения Lean мышления такие действия являются потерями — они не ведут к достижению ценности, а значит, они совершаются «впустую» и даже в минус (потому что та же самая энергия и время могли быть инвестированы в полезные действия).
В этом смысле ретроспектива в Скраме позволяет обнаружить эти «потери» и устранить их. В результате — ваша команда будет делать только полезные действия, только то, что является важным и ведет к получению ценности (как бизнесом, так и вашим клиентом).
Тем не менее, эти вопросы не могут определить всю суть ретроспективы. Недостаточно просто задать эти три или пять вопросов, услышать ответ — и разойтись. Как это всегда бывает в мероприятиях в Скраме, важно то, что происходит во время обсуждения этих вопросов: что именно осознают члены команды, какие новые решения принимаются, насколько есть понимание и согласие друг с другом.
Скрам–команда должна быть единой и целостной системой. Ретроспектива должна развивать и укреплять эту целостность.
Первая ретроспектива
Ребята, материалов в интернете о том, как проводить ретроспективу масса, а каждый раз приходится составлять скрипт с нуля. Буквально каждый день запускается команды, назначаются скрам-мастера, а им в свою очередь нужен простой готовый формат «делай как я», чтобы потом можно было применить на практике.
По мере подготовки сценариев, они будут публиковаться в нашем блоге и ссылки в группе в Facebook.
Сценарий ретроспективы: Первая ретроспектива.
Этот сценарий рекомендуется тогда, когда у команды давно не было ретроспективы (месяц и более) и вам нужно вдохнуть в них свежий воздух перемен.
Ретроспектива — это встреча, которая позволяет команде выявить собственные зоны роста, разработать изменения, организовать решение текущих проблем и предотвратить текущие трудности.
Цель ретроспективы: совершенствование рабочих процессов.
Время проведения: около 2-х часов
Участники: вся команда
Цели этапов ретроспективы:- Открытие.: «разогреть» и познакомить участников
- Сбор информации.: создание общего контекста для текущей ситуации
- Проникновение в суть: проанализировать причины текущей ситуации
- Генерация идей: поиск идей для решения текущей ситуации
- Разработка плана: выбор идеи и составление плана ее реализации
- Закрытие: подведение итогов церемонии и завершение групповой коммуникации на позитивной ноте.
Прежде чем начать, вам нужно убедиться, что у вас есть достаточное место для того, чтобы вся команда могла сидеть по кругу и между вами не было никаких столов. Т. е. чистая комната, стулья, флипчарт и на стены есть возможность клеить листы флипчарта на малярный-скотч. Обеспечьте возможность участникам видеть и разговаривать друг другом без каких-либо препятствий. Эта обстановка побуждает, естественным образом, отказываться от ноутбуков и мобильных телефонов. Запаситесь большим количеством стикеров, маркеров и малярным скотчем.
Имаджинариум (открытие)
Для проведения этого упражнения, вам понадобятся карточки с креативными картинками.
- Каждый участник получает по 3 карты.
- Фасилитатор спрашивает у группы за какой период будем проводить ретроспективу? (Это может быть спринт, календарный месяц, квартал или какая-то произвольная дата, но которая что-то значит для команды)
- Дальше за 3 минуты участники придумывают, как с помощью имеющихся картинок рассказать о том, что было за прошедший период. Важно, чтобы участники делали это молча и самостоятельно. Это индивидуальное упражнение.
- Каждый, по очереди, в произвольном порядке, выходит перед командой и рассказывает свою историю и показывая картинки.
- Хлопаем каждому участнику, в конце выступления, — это позволяет создать доверительную атмосферу и снимает страх выступления для интровертов.
График эмоций (сбор информации)
Рисуем график с горизонтальной линией по середине. Размечаем на нем период за который мы делаем ретроспективу с указанием промежуточных точек. Это могут быть понедельники, дни или месяца в зависимости от продолжительности рассматриваемого периода. Цель, чтобы у команды было 3-5 опорных точек, к которым они смогут привязывать свои события и понимать масштаб одинаково.
Рисуем вертикальную шкалу — это эмоции. Точка — 0, это нейтральное положение, чем выше от нее, тем сильнее положительная эмоция, и чем ниже, тем сильнее негативная. Эмоции нужно называть, чтобы другие участники могли понять, что чувствовал в этот момент выступающий и, возможно, проявить к нему эмпатию.
- 2 минуты на подумать — молча и самостоятельно
- По одному выходить к графику и рисовать линию, как изменялась его эмоциональное состояние на протяжении указанного времени
- В точках, где настроение стало расти, падать или идти ровно, нужно спрашивать, а что там было. Записывать факт (упал стенд, был в отпуске, остался без поддержки, выпустили релиз и т. д.) этого события и клеить стикер в место, когда он случился.
- Группа при этом может задавать уточняющие вопросы. Дискуссия идет только между выступающим и одним из участников. Беседы между участниками, нужно пресекать. У них будет время это все обсудить.
- По результатам у нас получается общая карта настроений команды и факты, которые имели место быть у команды. Этим мы собрали информацию из каждого, получили объективную картину команды на произошедшие события, помогли им вспомнить или узнать, что было.
Пять Почему. (проникновение в суть)
- Собираем все негативные факты, что удалось собрать на предыдущем этапе и клеим их в один вертикальный ряд
- Делим участников на группы по 3 человека:
- кол-во участников делим на 3.
- Округляем до целого в меньшую сторону.
- Просим по порядку рассчитаться от 1 до вычисленного числа.
- Указываем группе места, где с каким номером нужно собраться людям с одинаковым номером
- По каждому факту (сверху вниз), нам нужно понять корневую причину. Этим займутся группы. 3 минуты на написание одной корневой причины от группы на стикер.
- Фасилитатор составляет таблицу со столбцами Номер, Факт, Корневая причина, Решение, Ответственный, Срок выполнения.
- Представитель от каждой группы выходит к таблице и на группу рассказывает, какую они корневую причину возникновения данного факта нашли. После этого клеит стикер в строку соответствующего факта. Выслушиваем представителей от всех групп. Фасилитатор допускает дискуссию только между выступающим и один из представителей группы. Лучше придерживаться формата уточняющего вопроса.
1+1 = 1 (Генерация идей)
Прежде чем начать придумывать решения, нам нужно прогреть нейросеть участников в направлении креатива. Для этого предлагается использовать упражнение 1+1=1. Метафора такая: если мы соединим одну каплю с другой, то в результате у нас будет не две капли, а одна.
- Просим участников взять по одному стикеру
- Каждый в тайне друг от друга пишет название предмета, которое начинается с первой буквы его имени
- Находит себе пару, лучше чтобы это был не сосед
- За 1 минуту, каждая пара должна придумать, что за предмет у них получится, если объединить те, что записаны у них на стикерах, а так же придумать ситуацию где и как это можно использовать
- один из представителей пары рассказывает на всю группу, что получилось
Brainstorm (разработка плана)
- Проводим голосование группы за карточки с фактами. Каждый участник ставит не более 3-х точек за карточки, которые для него наиболее важные. Один человек может поставить только одну точку на одну карточку
- Подсчитываем голоса и сортируем их по убыванию в нашей таблице.
- Договариваемся с группой, сколько проблем мы хотим разобрать на сегодняшней ретроспективе с учетом оставшегося времени
- По каждой проблеме, в тех же группа за 3 минуты придумываем, обсуждаем и записываем на стикеры решения, которые помогут решить соответствующую проблему. Фасилитатор помнит, что участники пишут одно решение на одном стикере и открывают стикеры в блок или вниз, чтобы не топорщились прикленными. Количество предлагаемых решений — ограничено здравым смыслом
- Представитель каждой группы выходит и выклеивает все найденные решения, группа может задавать уточняющие вопросы
- После того, как все выступят, фасилитатор задает вопрос группе: «Хочет ли кто-то взять на себя ответственность за какое-либо решение?»
- Если доброволец найден, спрашиваем какое решение он/а готов на себя взять, рядом с этим решением записываем его Имя и Фамилию и срок, когда он это сделает
- Если не найден, то спросить группу почему они не хотят брать на себя ответственность, возможно это, либо низкая зрелость группы и тут нужна помощь Лидера группы (это может быть скрам-мастер, владелец продукта, мастер потока и т. д.), либо решение лежит вне зоны контроля или влияния команды и ее нужно эскалировать наверх (договориться, кто это сделает)
- Решение может быть коллективным и бессрочным. Какая-то хорошая практика (всегда читать полностью задачу, заносить все в Jira и т. д.). В этом случае применяем упражнение Римское голосование. Спрашиваем группу: все ли готовы выполнять новую практику. Палец вверх — я согласен, Палец горизонтально — я соглашусь с большинством, Палец вниз — я не согласен. Если несогласных нет — то решение принимается, а иначе нет и переходим к следующему пункту.
- Смотрим на время, если до конца ретро осталось меньше 15 минут, то переходим к следующем этапу, если больше, то берем следующий по важности вопрос и прорабатываем уже его.
Ретро ретро (закрытие)
Ретро, как и любая другая активность нуждается в улучшении и подстройке под каждую конкретную команду. Фасилитатору это помогает подбирать соответствующие упражнения для группы. Кто-то отказывается от разминок, кто-то просит в следующий раз чего-нибудь новенького и т. д. Каждая команда уникальна.
Ну и конечно, это в каком-то виде обратная связь от группы к проведенному мероприятию
Спасибки (закрытие)
Открытие, как и закрытие ретроспективы должно проходить на сильных позитивных эмоциях, которые сплочали бы команду. На этом упражнении не должно быть дискуссии. Каждый по очереди говорит кому конкретно он хочет сказать спасибо и за что. Фразы: «всей команде», «всем спасибо» — не годятся.
После того, как все воспользовались возможностью сказать Спасибо, все хлопают в ладоши и расходятся в хорошем настроении.
——
Друзья, успехов вам, в фасилитации ваших ретроспектив!
- невозможность распарраллелить работу приводит к простою
- медленная работа приводит к медленному прохождению pull request’ов