Что сказать на ретроспективе
Ретроспектива проекта, на которую команде захочется приходить
Как часто вы скучали на ретроспективе проекта? Как часто вы злились, что тратите на эту встречу целый час своего времени, пока рядом грустно догорает очередная задача? Слушали ли вас на ретро, или каждый ждал своей очереди, чтобы сказать пару формальностей и вернуться к работе? Мне однажды это страшно надоело. В этой статья я буду говорить о том, как с помощью простых правил мне удалось сделать ретро самой теплой встречей команды, не считая корпоратива.
Ретроспектива проекта — это обсуждение командой возникших проблем на проекте и способов их решения. Кроме того, правильно проведенная ретро несет в себе еще и психологическую разрядку для команды.
Для начала определимся, когда можно и нужно проводить ретроспективу.
Для полезной ретро у вас должны быть:
В каком формате лучше всего собирать обратную связь
Конечно, если вы просто попросите обратную связь от команды, вы рискуете стать обладателем объемной, эмоциональной и неструктурированной информации, с которой невозможно работать.
Лучше всего, если у команды есть общая таблица.
Скажу откровенно, таблица обратной связи, пожалуй, одна из самых важных составляющих качественно проведенной ретро. Таблица, которую я использую, состоит из двух последовательно заполняемых командой частей.
Первая часть — это описание проблем и столбец под вариант решения, принятый на встрече.
Замечательно, если проблемы пишутся обезличено, а обсуждаются уже непосредственно на встрече, где сотрудник сможет остаться неназванным, если он того не захочет.
Также хорошо, если в таблице есть два столбца для описания проблемы: столбец для проблемы технической/организационной и т.п., и место для ора. Таким образом мы ненавязчиво помогаем коллеге разграничить свои чувства от конкретных проблем.
В моей таблице обычно есть два столбца для того, чтобы команда смогла поделиться эмоциями. В первом я даю возможность людям выбросить свой негатив, отвечая на вопрос: «Что было плохого?». После того, как праведный гнев был освобожден и прожег глаголом сердечки сочувствующих, я задаю вопрос-нейтрализатор: «Что было хорошего?». Обсуждать с коллегами не только негативные моменты даже самых трудных, рывковых, спринтов, крайне важно. Даже если спринт не удался, а у вам на почту валятся громогласные письма от клиента, команда должна найти позитивные моменты этого опыта. Вашей команде необходимо учиться самим находить позитивные моменты даже в самых трешовых ситуациях.
Вторая часть — это голосование. Разумеется, для каждого сотрудника собственная боль и мнение являются приоритетными. Но стоит помнить, что мы работает в команде. После того, как все проблемы были обсуждены, весь ор выслушан и найдены позитивные моменты, стоит выделить три главные проблемы (и их решение), которые вы и ваша команда будет внедрять в течение следующего месяца.
Не пытайтесь решить на ретро все проблемы скопом, это невозможно. Постарайтесь на каждой ретро соблюдать правило:
Три проблемы — три решения
Еще месяц вы потратите на внедрение этих решений, привыкание команды к изменениям и выявление подводных камней. Отлично, когда приоритеты этих проблем расставляет команда. Для этого у нас в таблице есть часть с голосованием.
Голосование проходит крайне просто: у каждого члена команды есть три голоса, которыми он волен распорядиться как угодно. Он может поставить все три голоса на приоритет единственно важной для него проблемы, или отдать по голосу за каждую свою боль. Дайте команде время подумать, не торопите их. По результатам голосования выделите три проблемы цветом и не забудьте вернуться в ним в следующую ретро для закрепления результата и разбора подводных камней.
А теперь я хочу сделать вашу жизнь немного проще. Для тех, кто еще ни разу не проводил ретро, ниже есть пошаговая инструкция, как начать такое благое дело>
Шаг 1
Определяем, нужна ли нам ретро. Выделяем на ретро два часа времени. Желательно провести ретро через день после релиза, когда хотфиксы уже накачены, команду отпустило и еще не накрыло новыми задачами с головой.
Шаг 2
Создаем таблицу.
Шаг 3
Собираем команду на пятиминутный стендап. Тезисно рассказываем, что это за зверь такой «эта ваша ретро», показываем таблицу.
Шаг 4, который важно не игнорировать
Выделяем каждому члену команды по 30-40 минут из расписания на заполнение таблицы. Пусть они знают, что у них есть на это время. Пусть они смогут спокойно ее заполнить.
Шаг 5
Приготовьтесь, что первая ретро пройдет отвратительно. Ждите, что в вашей таблице будет либо мат, либо пустые строки. Пока ваша команда не поняла, зачем вы это делаете, и для них это — пустая трата их драгоценного времени, в которое можно сделать что-нибудь полезное. Наберитесь терпения и будьте лояльны. Подготовьте положительные нюансы прошедшего спринта, занесите их сами в таблицу. Ах, да. Запаситесь успокоительным.
Шаг 6
Предложите коллегам приходить на ретро с кофе/чаем, задайте традицию «сладости на ретро к чаю» самостоятельно. Начните с озвучивания негативных и позитивных эмоций. Снимите негатив с команды, посмейтесь и поругайтесь все вместе. Эту часть часто пропускают, так как она малопродуктивна с точки зрения производства. Но для вас и вашей команды она важна. Если команда написала только негатив, предложите свои плюсы, послушайте отклик.
Важное правило ретро:
Не команда слушает вас. Вы слушаете команду.
Шаг 7
После переходите к озвучиванию проблем. Следите, чтобы на этом этапе команда уже вернулась в рабочее состояние и была готова к решению трудностей. Когда вы обсудили все трудности, есть наброски решений или уже сложившийся план решений, зафиксируйте их в таблице.
Шаг 8
Голосование. Поясните, что у каждого члена команды есть три голоса. Они могут распределить их по своей свободной воле, в зависимости от того, у кого какая проблема больше «болит», и ее решение для данного члена команды критично. Дайте коллегам время на голосование.
Шаг 9
Выделите три проблемы, которые будете решать выбранным способом. Поблагодарите коллег за встречу.
Шаг 10
Создайте таски для решения выделенных вами проблем и назначьте ответственных. Убедитесь, что у ответственных есть на это время.
Шаг 11
Будьте последовательны и ритмичны. Раз в месяц (или с иной периодичностью) у вас ретро. Все решения, которые выделены на ретро априори или внедряются, или выносятся на следующее обсуждение, как провалившееся решение, для поиска нового.
Если у вас есть возможность проводить ретро от случая к случаю, с текучей командой и за 20 минут, лучше не проводите встречу вовсе. Поберегите нервы своих коллег.
Сделайте ретро хорошей традицией. Вам окупится.
Проведение ретроспективы по методу шести шляп
В следующие несколько абзацев хочу поделиться не так давно случившимся у меня опытом проведения ретроспективы по методу шести шляп. Метод шести шляп (англ. Six Thinking Hats) — метод организации мышления, помогает взглянуть на проблему с разных сторон, а также одна из разновидностей мозгового штурма при работе в команде.
Интересно будет тем, кто ищет новые способы проведения ретроспектив, кто интересуется командной работой, подходами к принятию решений и генерации идей.
Цель текста — рассказать, что такой метод есть, на основе простого примера показать, как его можно использовать для организации ретроспективы; вызвать интерес у читателя для дальнейшего самостоятельного изучения этого метода.
Вместо вступления
Идея использования метода шести шляп для проведения ретроспективы возникла, когда я искала интересные варианты проведения ретроспективы для студентов-разработчиков: перед ребятами стояла задача сделать студенческий портал, спринт = 1 неделя, в конце недели — ретроспектива на одну пару (пара — 1.5 часа). Очень хотелось организовать пару в таком формате, чтобы заинтересовать даже тех, кто не принимает активного участия в непосредственной разработке, и тех, у кого сам процесс разработки портала не вызвал какого-то воодушевления. Ещё одно из немаловажных условий — поделиться знанием, которое в дальнейшем ребята могли бы использовать в том числе в своей повседневной жизни (как оказалось, никто из присутствующих до пары об этом методе не слышал).
Что такое метод шести шляп
О методе шести шляп достаточно много написано в самых различных источниках и применительно к решению самых разнообразных задач. Ниже я лишь вкратце расскажу, что это такое.
Метод шести шляп — это метод организации мышления, один и популярных способов проведения мозгового штурма.
Не секрет, что человеческое мышление очень хаотично: тут и эмоции вперемешку со здравым смыслом, и интуиция, и факты. А что, если в следующий раз, когда нужно будет принять решение или сгенерировать идею, последовательно применять: факты; чувства; критическое мышление; позитивный взгляд на проблему; творческое мышление? Если говорить в контексте метода — примерить каждую из шести шляп: белую (информация и факты), красную (эмоции и чувства), чёрную (критическое суждение), жёлтую (оптимистичность), зелёную (креативность). Ещё есть синяя шляпа — в ней осуществляется обсуждение организации процесса последовательной «примерки» шляп (более подробно можно прочитать, например, в статье на Википедии — там отлично расписана каждая из шести шляп и приведены примеры).
Круто, а как это поможет при проведении ретроспективы?
В самом незамысловатом понимании Ретроспектива — встреча с командой проекта по завершению спринта с целью обсуждения этого самого спринта, его результатов: классические «Что было хорошо?», «Какие были проблемы», «Какие идеи по улучшению?», «Что запланировали на следующий спринт?». Т.е. нужно озвучить и осознать командой проблемы, с которыми команда столкнулась во время спринта, отметить позитивные моменты, придумать, как эффективно жить дальше, при этом очень важно, чтобы ни один член команды в стороне от обсуждения не остался.
И круто взглянуть и на прошедший спринт с разных позиций и по возможности не упустить ничего важного. Не слукавлю, если скажу, что ретроспектива — это ещё и возможность сплотить команду. И метод шести шляп может стать эффективным инструментом во всём этом.
Например, расскажу, как это происходило у нас. В первую очередь очень важно было, чтобы ребята не забывали, какова цель нашей встречи. Для этого, например, можно перед глазами поместить план ретроспективы:
Всё это — основные цели проведения ретроспективы (взято отсюда).
После того, как у команды есть общее представление о методе, самое время погрузиться в него, и начать с синей шляпы.
Синяя шляпа = управление
Как я уже отметила выше, синяя шляпа — организация и обсуждение процесса, в нашем случае ретроспективы. В контексте аджаила синяя шляпа — шляпа скрам-мастера на время всей ретроспективы (именно он организует процесс обсуждения и следит за его последовательностью и эффективностью).
На этом шаге нужно рассказать, как сегодня будет проходить ретроспектива по методу, например: команда поочерёдно примерит каждую из шляп, это поможет взглянуть под разным углом на основные вопросы ретроспективы (те, что на картинке выше). При этом очень важно ограничить по времени пребывание в каждой из шляп (на сколько — зависит от того, какая продолжительность ретроспективы запланирована изначально) — так команда успеет обсудить важное и не успеет погрузиться в ненужные дебри. Ну не забыть оставить время на подведение итогов.
Важно, чтобы вся полученная на ретроспективе информация была зафиксирована, а при использовании метода шести шляп, ещё и структурирована. С этой целью я вывела на маркерную достку слайд:
— предполагается, что все озвученные мысли будут записываться под каждой из шляп (в зависимости от того, в какой шляпе мысль была сгенерирована).
Белая шляпа = информция и факты
Здесь каждый озвучивает факты о текущем спринте, например:
Красная шляпа = эмоции и чувства
В этой шляпе участники команды озвучивают свои чувства от прошедшего спринта, демонстрируют эмоции (важно при этом, чтобы не было переходов на личности). Как и факты, эмоции и чувства могут быть как позитивные, как и негативные, но главное, чётко сформулированные.
Тут можно бросить взор на уже зафиксированные факты и критиковать их (объективно критиковать). Например,
Жёлтая шляпа = оптимистичность
В этой шляпе мы выделяем позитивные моменты: что было хорошего в спринте («По итогу спринта команда отлично сработалась», «Петя, оказывается, крутой фронтенщик! Очень помог нам с такой-то задачей», «Показ прошёл здорово, мы молодцы»), что будет хорошего («С таким фронтенщиком как Петя. » — ну вы поняли).
Зелёная шляпа = креативность
К этому этапу у команды уже зафиксированы факты о работе во время спринта, выделены минусы и плюсы. Самое время взглянуть на всё это ещё раз: как избежать озвученных минусов в следующем спринте? Как не растерять и использовать плюсы в следующем спринте? Здесь мы генерируем и фиксируем идеи того, как улучшить работу команды на следующий спринт.
По результатам проведения ретроспективы у команды должен быть план улучшений на следующий спринт — он формируется из того, что было нагенерировано в зелёной шляпе. О том, как должен выглядеть план улучшений по результатам ретроспективы, писать не буду — в рамках этой статьи такой задачи не стоит.
Вместо заключения
Выше — небольшое описание того, как можно провести ретроспективу по методу шести шляп. Надеюсь, что статья помогла открыть что-то новое для себя и/или структурировать существующее восприятие. Не было целью рассказать, что такое ретроспектива, и даже цели написать инструкцию, как проводить ретроспективу по методу шести шляп не стояло, просто хотелось рассказать, что бывает ещё вот так — знайте это и используйте это знание. Крутых и занимательных ретроспектив вам 🙂
Ретроспектива по шагам. Рецепт
Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, «обучающих» материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.
Кто присутствует
Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в «не туда», и по его итогам даже не понятно, а почему и как это исправить.
В будущем проведение (фасилитацию) ретро можно передать члену команды, а через некоторое время выбирать нового фасилитатора для каждого нового ретро.
Когда
Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. «Сила» методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.
Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.
Что нужно для ретро?
Если ретро проводится в «реальном мире», потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.
В «виртуальном» мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать «плюсы», «минусы» и «действия».
Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.
Начало ретро
(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.
(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.
Другое важное назначение «+»-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point’ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.
Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от «проблемы +1», когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает «слепое» покер-планирование).
Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).
Вполне можно и допустимо сюда писать что-то, что на первый взгляд кажется «внешним» по отношению к команде. Потому что потом на детальном разборе может оказаться, что при внешней причине мы можем что-то поправить в процессе внутри команды.
Анализ
Минусы. Самый сложный этап. Игра в доктора «наоборот».
Берём каждый стикер (присланный нам в персональные предложения пункт) и. не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И «лечение» самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.
Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point’а). Например. Член команды записывает на стикере «у нас неоптимальный CI-скрипт«. Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?
Уточняем у члена команды, «[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален»? Внезапно оказывается, что:
скрипт медленно работает
медленная работа приводит к медленному прохождению pull request’ов
невозможность распарраллелить работу приводит к простою
это приводит к медленной работе члена команды
скрипт работает недетерминированно, иногда проваливаясь из-за фазы луны и положения Сатурна в созвездии козерога
это приводит к необходимости ручного перезапуска CI
это приводит к медленной работе члена команды
Но зато для каждого следующего более общего уровня можно предложить самые разные варианты решения проблем:
поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно
поставить посильнее машину для CI
выкинуть часть действий из CI-скрипта, не переписывая его кардинально
полностью переписать CI-скрипт
научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI
сделать простой скрипт для перезапуска failed-сценариев 2-3 раза
Но пока что возможный список даже не озвучиваем. Но мы должны (из своего опыта) как-то понять, что именно та формулировка, которая будет записана, может, хотя бы в теории, быть решена несколькими разными способами. И вот именно эту формулировку и надо записать в «минусы».
Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, «нет, это вовсе не то, что меня беспокоит, меня беспокоит другое». Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.
Голосование
Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных «минусов» было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их «минусы»).
В результате формируется отсортированный «по голосам» список проблем.
Блиц-этап
60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.
Перерыв на кофе
Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/выпить/отойти проверить почту.
Обсуждение. Action Points
Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?
Во-вторых, решения должны проходить валидацию у тех, чьи проблемы были изначально сгруппированы в единый «пункт симптомов болезни». Хотя бы один из них должен подтвердить, что предложенное решение действительно сделает его жизнь проще.
В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.
Плохой вариант
Вариант получше
Нужно устроить встречу и обсудить розовых единорогов
[Олег] устраивает встречу во-вторник в 15 часов по обсуждению проблемы питания розовых единорогов
Ответственно подходить к ревью pull request’ов
— (или) при отклонении pull request’а оставлять комментарий
— (или) настроить бота, назначающего PR на ревью на членов команды
— (или) добавить в CI-скрипт автоматический линтер, а все проблемы в оформлении, которые им не покрываются не считать проблемами
заранее формулировать тикеты в jira до планирования
[Олег] заведёт в outlook еженедельный backlog grooming до планирования с участием владельца backlog’а, представителя аналитиков и solution-архитекторов смежных систем
Полученные шаги записываются в action point’ы.
Почему ретро может не помочь
Может так случиться, что сделали всё по рецепту, а огонёк в глазах команды всё тусклее и тусклее, а производительность команды падает. Потому что автор этого текста ни хрена не знает. Ретроспектива в этом случае позволяет найти часть этих причин, и задуматься, почему эти причины до сих пор не исправлены.
Признаками проблем являются:
Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды «как у нас всё хорошо, как здорово и дружно мы живём, дорогой дедушка Ленин«. Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.
Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point’ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!
Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы». Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.
Невыполненные action point’ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.