Бытует мнение, что ретроспектива это скучная встреча без явной пользы. Если ставить цель, фиксировать прогресс и подбирать интересный формат ретроспективы, то польза от этой командной встречи не заставит себя ждать. В статье вы найдете 3 варианта эффективных ретроспектив, проводимых в командах разработки Ozon.
План:
Наш кейс
Команда, состоящая из удалённых специалистов, которые друг друга никогда не видели и приходят на видеозвонки с аватарками, — наш случай. Я думаю, такой кейс знаком многим в IT-индустрии.
Мы проводим ретроспективу в конце каждого спринта, то есть раз в две недели. Сначала участники команды были пассивны, часто отмалчивались — и ретроспектива превращалась в монолог технического лида. Взаимодействие внутри команды было похоже на многоэтажный дом, где никто никого не знает, никто ни с кем не разговаривает, но при этом регулярно возникают проблемы: с верхнего этажа затопили, мусор оставили не там, где надо, в подъезде накурили.
С техлидами мы старались наладить коммуникацию и превратить ретроспективу в открытое общение, поэтому стали экспериментировать с форматами. Некоторые подходы показали хорошие результаты, поэтому я решила ими поделиться.
Польза от данных форматов ретроспектив:
задействованы все члены команды;
атмосфера способствует открытому общению;
становится легче разговаривать и понимать друг друга на созвонах;
появляется ощущение коллектива и командной работы.
Теория ретроспективы
Обучение менеджеров под одну копирку Agile, Scrum, Kanban привело к тому, что у многих сложился однобокий взгляд, что такое ретроспектива и как ее проводить. Как правило, на таких встречах обсуждаются три вопроса:
Что было хорошо?
Что было плохо?
Как улучшить то, что было плохо?
Описание ретроспективы из Scrum гайда звучит следующим образом:
Цель Sprint Retrospective — запланировать повышение качества и эффективности… Участники Scrum Team обсуждают, что прошло хорошо во время Sprint, с какими проблемами они столкнулись и как эти проблемы были (или не были) решены.
Напомню, что Scrum в США стали практиковать в 1990-х, а в 2010 году появился альманах Scrum Guide. В то время команды разработки в основном трудились в офисе, много общались и взаимодействовали. Они обедали вместе, пели в караоке на корпоративах и обменивались новостями из личной жизни в курилке.
Ситуация сильно изменилась в 2020 году, когда из-за пандемии многие стали работать удалённо. Теперь специалисты IT-компаний не ходят в офисы и не встречаются со своими коллегами вживую. Они практически не знакомы друг с другом, поэтому им сложно открыто и эмоционально выражать свои мысли. Для эффективной командной работы необходимо событие, сближающее людей. Таким образом, целью ретроспективы, помимо обсуждения итогов работы и планов на будущее, становится мини-тимбилдинг, или замещение курилки (где раньше происходило открытое общение, знакомство, обмен взглядами на мир).
Практикующие Agile компании активно развивают церемонии при удалённой работе, создают новые инструменты. На английском языке можно найти множество хороших идей для ретроспектив, в том числе шаблонов для онлайн-досок для совместной работы (Miro, Figma и т. д.). Список источников я приведу в конце статьи.
Адаптировав для нашей компании несколько идей, я проводила ретроспективы в четырех IT-командах, относящихся к одному продукту. Атмосфера в командах разная, поэтому ретроспективы тоже отличались, однако всегда они проходили активно и помогали людям раскрыться. В процессе у меня появились свои идеи, подходящие под специфику команд. Далее я расскажу про три формата, получивших лучшие отклики от коллег.
Варианты ретроспективы
Колесо фортуны
Это ретроспектива в виде викторины с заранее подготовленными вопросами. Её цели — вовлечь всех членов команды, получить ответы на вопросы и немного повеселиться. Интрига, кому достанется вопрос, помогает удерживать внимание участников на протяжении всей встречи.
Для такой ретроспективы понадобятся:
поле, где будут представлены вопросы (редактировать участники команды его не будут — это прерогатива фасилитатора);
онлайн-колесо фортуны, которое нужно заполнить именами участников (пример: Random wheel);
вопросы для викторины (их должно быть в полтора—два раза больше, чем участников).
Ход ретроспективы
Выберите один вопрос из списка на стикере и поместите его в центр поля.
Раскрутите колесо фортуны и определите отвечающего.
Отведите максимум три минуты на ответ. Задавайте дополнительные вопросы, если он слишком короткий.
Если ответ засчитан, удалите отвечающего из списка отвечающих.
Последнему участнику можно дать возможность выбрать вопрос из оставшихся.
В процессе ретроспективы формируйте список договорённостей, а в конце — подведите итоги и напомните о планах на следующий спринт.
Личный опыт
Этот формат ретроспективы спас одну из команд, когда она разрослась до 20 с лишним человек. На другие форматы не хватало времени, либо при дискуссии не было времени выслушать всех участников, желающих высказаться.
В «Колесо фортуны» каждый член команды был минимум 1 раз в роли отвечающего. Плюс, пока крутилось колесо фортуны, все готовились отвечать на вопрос.
Вопросы я формулировала по рекомендациям в интернете, просила технических лидов рассказать, что им важно и интересно узнать у участников команды, чередовала серьёзные болезненные темы и вопросы для веселья и знакомства.
Благодаря разнообразным вопросам про работу и личную жизнь удалось узнать много интересных фактов об участниках команды. В ходе ретроспективы было много шуток и обсуждений. Появилось ощущение коллектива и командной работы.
Примеры вопросов:
Из того, что ты создал(а) для пользователей, что имеет наибольшую ценность?
Расскажи про авторов, блогеров из твоей профессиональной сферы, которых ты читаешь/смотришь/уважаешь.
У тебя получается соблюдать баланс между работой и личной жизнью?
-
Что бесполезного тебе приходится делать?
Таймлайн
Ретроспектива в этом формате проводится на онлайн-доске для совместной работы (Miro, Figma и др.), которую все члены команды могут одновременно редактировать. Поле представляет собой временную ленту с промежутками. Участники команды делятся воспоминаниями о важных событиях и обсуждают возможные решения в случае трудностей.
Есть два варианта:
1. Обсуждение итогов года: размечаем временную ленту по месяцам (январь—декабрь).
2. Обсуждение итогов спринта: временная лента размечается по дням недели.
Предварительно необходимо подготовить поле для ретроспективы и «заморозить» его, чтобы при заполнении членами команды ничего не двигалось. Для команд, состоящих из 6—12 человек, я рекомендую проводить ретроспективы продолжительностью полтора часа.
Ход ретроспективы
Предложите членам команды включить камеры, чтобы было комфортнее вести беседу.
Продемонстрируйте доску и расскажите о правилах. Покажите пример создания и заполнения стикера.
На стикере напишите значимое событие. Оно может быть как хорошим, так и плохим: повышение, решение сложной задачи, помощь со стороны коллеги, ошибка в разработке, конфликтная ситуация. Стикер поместите в столбик месяца/дня, когда произошло событие.
Порекомендуйте каждому сделать не менее двух стикеров и выделите на это пять—десять минут.
Когда все завершат заполнение стикеров, разберите ответы членов команды. Начните с общих итогов, например обсудите, в каком месяце или в какой день произошло больше всего запомнившихся событий. Далее разберите каждый стикер отдельно и попросите его автора пояснить содержание (почему данное событие для него памятно).
В конце ретроспективы попросите участников проголосовать — и выберете самое яркое событие периода.
Личный опыт
В командах ребята были склонны отмалчиваться и ничего не делать на ретроспективах. Поэтому для каждого участника я заранее готовила стикеры определённого цвета — чтобы на доске сразу было видно, кто вовлечён в процесс, а кто — нет. Также я зачитывала часть текста со стикера и просила его автора прокомментировать её, задавала наводящие вопросы, чтобы человеку было проще делиться воспоминаниями. Примеры таких вопросов:
Почему тебе было важно выполнить эту задачу?
Как ты себя чувствовал(а) после конфликтного разговора с коллегой?
Воспоминания о задачах прошедшего спринта помогали командам прочувствовать результаты своей деятельности. Ушло ощущение, что время пролетело, а ничего не сделали. Стала нагляднее рутина, на которую нужно отводить достаточно большое количество ресурсов при планировании: поддержка, вопросы, встречи, настройка инструментов.
Здоровье продукта
Одной из самых методически продуманных и всеобъемлющих мне показалась ретроспектива «Здоровье продукта» компании Spotify. Она наглядно демонстрирует состояние команды с разных сторон: от качества кода до взаимоотношений в коллективе и времени на обучение. Участники команды ставят цветовую оценку тому, как они себя чувствуют в определённой сфере. Зелёная — «отлично», жёлтая — «средне», красная — «плохо». Из инструментов нужна онлайн-доска (Miro, Figma и др.) с предзаполненной таблицей. Разработчики будут на ней одновременно создавать стикеры, поэтому поле для ответов лучше подготовить заранее и «заморозить».
Ход ретроспективы
Продемонстрируйте доску и расскажите о правилах. Покажите процесс создания стикеров разных цветов.
Подробно разберите каждую область работы, которую нужно оценить.
Попросите участников команды оценить своё самоощущение во всех областях.
После заполнения поля стикерами разберите выраженные тенденции: в таблице вы сразу увидите, каких ответов в каких строках (областях) больше.
Разберите каждую область отдельно и попросите членов команды прокомментировать свои оценки.
Возникающие в процессе ретроспективы договорённости вносите в отдельную таблицу, в которой зафиксируйте также ответственных сотрудников и сроки.
Перевод полей с пояснением (авторский)
Источник: Spotify Health Check: Everything You Need To Know
Работа в команде
Хорошо — вы суперкоманда, у вас отличное взаимодействие.
Плохо — вы сборище индивидуалов, которые не знают (и не хотят знать), что делают окружающие.Поддержка
Хорошо — вы всегда получаете необходимую поддержку и помощь, когда о ней просите.
Плохо — вы увязаете в задаче, так как никто вам не хочет помочь.Пешка или участник
Хорошо — вы участвуете в принятии решений по задачам, над которыми работаете.
Плохо — вы только пешка в чьей-то игре, никто не интересуется вашим мнением.Миссия
Хорошо — вы точно знаете, как ваша работа помогает развиваться компании.
Плохо — вы не понимаете, зачем решаете свои рабочие задачи и как они влияют на бизнес.Здоровье кода
Хорошо — вы гордитесь качеством вашего кода (другого вида работы); всё чисто, ясно, покрыто тестами.
Плохо — ваша работа — «куча макулатуры», всё погрязло в техническом долге.Процессы работы
Хорошо — вас устраивает, как организована работа.
Плохо — неоптимизированные процессы мешают нормально работать.Ценность
Хорошо — вы создаёте полезные вещи для заказчиков, гордитесь своей работой.
Плохо — вы производите мусор, вам стыдно за свою работу; заказчики ненавидят вас.Обучение
Хорошо — вы постоянно на работе изучаете что-то новое.
Плохо — у вас никогда не хватает времени на обучение.Скорость
Хорошо — вы делаете свою работу очень быстро, без задержек.
Плохо — вы никогда не заканчиваете работу в срок, вас всё время что-то отвлекает.Простой процесс по релизу
Хорошо — релизить легко, безопасно, безболезненно, многое автоматизировано.
Плохо — релизить рискованно, больно, много ручной работы.Удовольствие от работы
Хорошо — вам нравится работа, вы получаете удовольствие от процесса.
Плохо — вам скучно на работе.
Личный опыт
Ретроспективу «Здоровье продукта» мы проводили в командах несколько раз с промежутками месяц и больше, так как ставить оценку каждый раз одним и тем же сферам утомительно. Заполненное стикерами поле демонстрирует состояние каждого члена команды и общее настроение группы. Нормальная ситуация: больше половины стикеров — зелёные, достаточно жёлтых стикеров, есть красные. В команде, состоящей из живых людей, всё поле зелёным априори быть не может.
Количество стикеров на одной из наших ретроспектив из 11 человек: 65 зелёных, 48 жёлтых, восемь красных.
Яркие всплески красных стикеров подсказывали нам, в какой сфере и у кого критичная ситуация. Их ребята ставили редко, и это было сигналом того, что всё плохо и требует обсуждения всех членов команды.
Хорошо продуманный список сфер с пояснениями помог подсветить проблемы и положительные стороны нашей команды, что в течение рабочих будней сделать сложно. Например, стало известно, что талантливой разработчице не хватает времени на чтение статей и развитие из-за слишком большого объёма задач. Другой коллега сказал, что, по его мнению, у продукта высокое качество кода (на его предыдущем месте работы уровень разработки был значительно ниже).
Не знаю, как часто и в каких командах проводят данную ретроспективу в Spotify (и проводят ли), но было бы интересно сравнить оценки и комментарии людей из разных IT-компаний.
Заключение и список источников
В статье представлено всего три варианта ретроспективы. На самом деле можно найти и придумать намного больше. Буду рада, если вы поделитесь своими идеями или оставите комментарии с фидбэком, когда проведёте какую-нибудь ретроспективу из моей подборки.
Для вдохновения скидываю хорошие источники идей ретроспектив (на английском).
Успехов вам и продуктивной работы команд! ????
Комментарии (34)
ruomserg
00.00.0000 00:00+3Нет, я понимаю — такие форматы в какой-нибудь студенческой лаборатории… Пива еще можно принести… Но во взрослом проекте, тем более по удаленке — на любителя, на любителя…
А не пробовали с разработчиками как со взрослыми людьми поговорить о процессах, об улучшениях, и т.д.? Я скажу вообще крамольную вещь — в развитой команде не надо ждать две недели до ретро чтобы поднять вопрос, если с процессом что-то не так… На ретро есть смысл уже конкретно воркшопить варианты решений.
В общем, в таком виде — ретро мне начинает напоминать карго-культ. :-( Хорошо что у нас в компании подобным не страдают.
Kaklendela
00.00.0000 00:00+1Согласно моим представлениям, разработчики все недалеко ушли от студентов )) на самом деле, и во взрослых коллективах многие предпочитают молча терпеть несовершенства, особенно если в целом атмосфера в фирме не располагает... а еще очень многие объективную критику воспринимают как личную обиду. Тут ко всем нужен свой подход)
ruomserg
00.00.0000 00:00Тут есть два пути — правильный, и простой. Правильный — это начинать относиться к разработчикам (даже если им 20+ лет) как ко взрослым людям. Правильный — это работать с лидами и сеньорами, чтобы разбивать традиционную для РФ ориентацию на иерархичные команды. Это учить разработчиков, что существует процесс разработки, и он не сводится только к стучанию по клавишам и изменению статуса тасок в трекере. Это учить замечать и признавать недостатки в процессе, не переходя на личности. В общем — это работа, в результате которой у вас получается нормальная самоуправляемая команда.
Простой — устроить геймификацию, налепить виртуальных цветных бумажек и проч. Невозможно на уровне цветных бумажек обсуждать реально сложные проблемы разработки и находить хорошие решения.
И последнее — если вы относитесь к разработчикам как к детям — они рано или поздно и ведут себя как дети. Потом начнутся проблемы с контролем: без внешнего контроля дети в школу не ходят и домашку не делают. В конце-концов, получается команда которая без постоянного «искусственного дыхания» со стороны менеджмента и скрам-мастера не может существовать. И зачем оно такое ?!
KaterinaTz Автор
00.00.0000 00:00+1Если вы считаете, что я отношусь к разработчикам, как к детям. Вы не правы. Чем вам помешали цветные стикеры, тоже не понимаю. Мне кажется, что онлайн-доски для совместной работы при большой удаленной команде крайне удобный инструмент, визуализиюрующий идею говорящего. Рост бизнеса Miro, FigJam и других инструментов тому свидетельство.
ruomserg
00.00.0000 00:00Тут произошло смешение веток. Я немного огорчился от мнения Kaklendela которая считает что разработчики недалеко ушли от студентов! Против цветных стикеров как таковых я тоже ничего не имею (например, когда мы воркшопим проблему — то тоже пользуем цвета чтобы не путать свои и чужие). Но вот к техникам типа «поля чудес» или использование стикеров для визуализации «хорошо/плохо/норм» — я уже как-то с подозрением отношусь. На первое — времени жалко (с нами скрам-мастер новая хотела в слова играть — мы вежливо попросили ее так не делать...). На второе — тоже жалко. :-) Я бы отправил это в виде опроса в почте/чате ДО сессии, а на ретро уже обсуждал бы результаты. Возможно, это разница в тактике ведения спринтов — у нас ретро раз в месяц… Было бы раз в две недели — может быть тоже маялись, чем бы себя занять…
KaterinaTz Автор
00.00.0000 00:00Буду благодарна, если опишешь подробнее, как вы проводите ретроспективу. Делитесь эмоциями или только решения задач разработки обсуждаете?
ruomserg
00.00.0000 00:00+2С эмоциями у нас местами тяжеловато, потому что интернациональная команда, и ретро на английском — а он у всех не очень родной. То есть рабочие вопросы мы все одинаково понимаем, шутки в тему более-менее тоже, а вот эмоций в описаниях немного — просто потому что лексики не хватает для развернутых эмоциональных фраз, а универсальные синонимы из четырех букв как бы запрещены. :-)
Вообще, ретро проходят по-разному, но к ним обязательно готовятся. Во-первых, там есть работа скрам-мастера, который отслеживает всякие метрики, обсуждает их с PO и Governance — и за которые у команды голова не болит каждый день. Чтобы не было искушения править метрики — SM обязан их интерпретировать, чтобы представить команде возможные проблемы и тренды, а не просто числа.
Дальше, есть обязательные топики — если, например, был инцидент на продакшене — ну значит стандартный воркшоп: как справились, где была root cause, что будем делать чтобы так больше не было. Если есть какие-то нехорошие ощущения у SM по поводу общения со стейкхолдерами и статистикой — ну значит вот это. Если кто-то из команды хочет что-то вынести на Retro — значит скрам-мастер будет с ним работать еще и 1-1 для подготовки информации. Плюс у нас принято, что все нововведения надо сначала проверить «на кошках». Например, выявили что у нас возникает проблема с параллельным выполнением задач из-за PR — придумали модификацию branch/merge стратегии. Ее не будут раскатывать сразу на всех — обычно есть инициативная группа добровольцев, которая будет ее на своих тасках использовать (возможно, дорабатывать). На ретро они расскажут свои ощущения от изменений — что хорошо, что плохо: дальше команда решит — раскатывать это дальше на всех, или пробовать что-то другое. Иногда по итогам ретро создаются рабочие группы добровольцев что-то посмотреть или почитать, чтобы не нагружать этим каждого девелопера в отдельности… Короче, все довольно плотно происходит — и не скучно, ну просто потому что обсуждаются и решаются реальные проблемы.
Я думаю, что пассивность на ретро — это во многом следствие ориентации команд на иерархию или незрелость. Либо команда не берет на себя обязанность организовать свою деятельность, ожидая что это будет делать менеджер, PO, техлид, тимлид и зеленые человечки с марса — либо просто не умеет это делать (например, если набрать в команду джунов — они настолько упахаются в кодинге в попытках исполнить обязательства — что на «подумать над процессом» у них уже ни сил, ни времени не останется). У нас на проекте приличное количество сеньоров и мидлов, а джун-подмастерье только один, и он далеко :-) Поэтому обычно по любому вопросу есть две-три разумные точки зрения. И дальше надо чтобы все эти безусловно умные, интеллигентные и убежденные в своей правоте люди — друг-друга не поубивали… А для этого надо синхронизироваться. Как-то так.KaterinaTz Автор
00.00.0000 00:00+1Добрый вечер! Спасибо, что описал формат вашего ретро! Ты первый, кто не только кляксу под статьей поставил, но и обозначил альтернативный вариант ретроспективы. Мне понравились практики разбирать инциденты и готовить с разработчиками тезисы для ретро заранее.
Наши команды разработки проводят действия, о которых ты пишешь. Например, инцидент на проде обычно разбирают на следующий день всей командой. До ретро не ждут. Ретроспектива же в командах направлена на общение и взаимодействие всей команды, всей группы.
Я не до конца понимаю такую многочисленную и объемную критику под своей статьей. Я описала ряд практик, которые помогают нашим командам хорошо работать. Тим лиды считают их полезными, разработчикам тоже нравится. Если они будут кому-то еще полезны, я буду танцевать. Если нет, то это меня мало касается.
Кстати, несколько менеджеров писали на linkedin, что попробуют использовать мои форматы в работе. Надеваю танцевальные туфли :)ruomserg
00.00.0000 00:00+1Я думаю, что ты видишь общий фон негатива связанный с культурой менеджмента в софт-деве. :) Точнее — с НИЗКОЙ культурой менеджмента в софт-деве. Точнее — в стране вообще. Когда в команду приходит менеджер или скрам-мастер без хорошего опыта, а после университета/курсов/переподготовки — он в попытке применять «аджайл» начинает делать не то, что нужно — а то что он может быстро сделать. То есть — внедрять ритуалы. И пофиг, что команда еще не умеет самоуправляться, пофиг на то что вышележащее руководство еще ни разу само не аджайл — и поэтому раздуваются скоупы уже начавшихся спринтов или ставится фиксированная дата (которую уже согласовали с заказчиком в договоре), и т.д. В результате — у разработчиков и так был гребаный цирк, где ты едешь на велосипеде, а он горит… — а теперь тот же цирк, но с дейли, демо, и ретро. При этом, обязанности выдавать годное (желательно — не меньше, а больше чем было до дейли, демо и ретров) обычно с них никто не снимает. Опять же, разработчики могут прекрасно понимать, что никакого реального самоуправления в команде и аджайла нет, а есть просто ритуалы которые им навязаны. Вряд ли можно ожидать положительной реакции умного и технически грамотного человека на бессмысленные ритуалы, подозрительно похожие на комсомольско-партийные собрания в СССР… Ну и так же как тогда, разработчики отвечают пассивностью. В ответ — менеджер или SM начинают брать методики и их тормошить, пытаясь вытрясти хоть какую-то реакцию. Что, разумеется, опускает их в глазах разрабов еще ниже…
В общем, это живая иллюстрация к тому, насколько плохо понимается и внедряется аджайл в разработке (и в бизнесе вообще). Соответственно, там где произошел сдвиг парадигмы в умах руководителей и оно внедряется не в виде ритуалов, а в виде бизнес-практик — таких отрицательных отзывов нет: все видят зачем это, и какие от этого получаются результаты.
ruomserg
00.00.0000 00:00+1… кстати, про инцедент на проде — у них есть некая логика, почем так. Считается что по горячим следам именно РАЗБИРАТЬ случай еще нельзя — можно только документировать. А вот к моменту ретро эмоционально-стрессовый фактор уже уйдет, и можно вернуться к вопросу. Европейцы — ранимые люди, что с них взять… :-)
KaterinaTz Автор
00.00.0000 00:00Хочу подсветить, что мы проводим разные ретро. Форматы меняем в зависимости от настроения группы и нужды обсудить какую-то тему. На этой неделе в четверг и пятницу проводили ретро про завершенные большие проекты. Было поле для описания положительного опыта и негативного опыта, при работе над конкретным проектом.
oracle_schwerpunkte
00.00.0000 00:00+2Ну, иногда это единственный вариант получить обратную связь. Стадный инстинкт работает даже для интовёртов, в личном разговоре он закроется, а на этом несерьезном совещании может и рассказать что нибудь полезное. То же для юниоров, они часто боятся рассказывать о проблемах один на один. А тут - все говорят, значит и я скажу.
Рассматривайте ретроспективу как вариант тим билдинга, возможность узнать немного больше о команде, а не как единственное место для улучшения рабочих процессов.
alisa_designagency
00.00.0000 00:00Для молодой компании, которая полностью на дистанционном, полезные практики! Спасибо за материал, заберу себе)
KaterinaTz Автор
00.00.0000 00:00Спасибо за отзыв! Буду рада, если потом расскажите, как прошли ретроспективы у вас в командах.
venanen
00.00.0000 00:00+5Сколько не было в моей жизни ретроспектив - я так и не понял, зачем, а главное нафига просто взять, и оттяпать 2 часа рабочего времени на что-то, похожее на детский утренник с серьезными словами. Нет, я все понимаю, есть какая-то крайне мало поддающаяся моему уму практика - устроить из любой вещи дичь, которая никому не нужна. Хороводы, падения на доверия, викторины, и прочий тимбилдинг имеющий тонкий привкус менеджерского безумия и явный и отчетливый запах испанского стыда. Но:
1) Мы тут вообще-то работаем, мы тут так-то взрослые, серьезные люди, и если у кого-то возникает проблема, он берет и сообщает о ней. Заранее, сразу, и не ждет 2 недели до ближайшего ретро, чтобы прилепить стикер;
2) Если в команде есть проблема, которая замалчивается по каким-то причинам - нет ровно ни одной причины, почему разработчик молчал, а теперь должен публично ее объявить;
3) Стикеры - это мое любимое. Дело в том, что сколько я бывал в командах, в результате взаимодействий команды все вопросы были решены, или было постулировано, что решение не найдено, и это задолго до ретроспективы. Но на ретро тебе говорят: придумай проблемы. И их реально сидят и придумывают и лепят стикеры, вместо того, чтобы решать единственную проблему - допилить все к релизу. Похоже на какой-то очень специфический KPI;
4) Эффекта я не видел ни разу. И никто из моих знакомых не видел. Ну, кроме того, что стикеры прилеплены - это да, а решений нет - потому что сложно решить проблемы, которой нет, которую вы придумали полчаса назад. А это еще и идет долго, если посчитать, сколько стоит бизнесу это развлечение - можно упасть со стула;
5) Все эти колеса фортуны, викторины, попытка втянуть каждого в разговор - это само по себе глупо, потому что среди разработчиков очень немало интровертов, и они разговаривать о 5 видах кошек, которых он видел на даче не особо хочется. Лучший результат который я видел - это когда в офис привезли пиццу - за пиццой и пивом разговор отлично клеится.
При этом стоит отметить, что те-же дейлики, или звонки с профильными командами - это очень позитивная практика. Полчаса делов и все по делу. А ретро - это что-то очень странное.KaterinaTz Автор
00.00.0000 00:00Привет! Спасибо за комментарий! Мне не совсем понятна его цель. Я описала в статье пользу от ретроспектив, которые я провожу.
задействованы все члены команды;
атмосфера способствует открытому общению;
становится легче разговаривать и понимать друг друга на созвонах;
появляется ощущение коллектива и командной работы.
Ее видят тим лиды и члены команды, с которыми я работаю. Если вы ее не видите, не используйте данные форматы.
Пиццу я тоже люблю. Только сейчас мы работаем на удаленке в разных городах и странах.
KaterinaTz Автор
00.00.0000 00:00Поясню свой комментарий "Если вы ее не видите, не используйте данные форматы."
Цель моей статьи - обогатить русский дискурс статьей про идеи ретроспектив. Когда я искала сама статьи на русском про ретроспективы, то ничего толкового не нашла. На английском подобных статей с идеями для ретро множество. Я не готова убеждать, что наши ретро полезны и их должны все проводить. У каждого своя команда и своя ситуация. Если вы бы были в поиске идеи для ретро, вы могли попробовать воспользоваться моими. Если нет, и у вас все хорошо с ретрами или без них, то вам они не нужны.
Я ответила достаточно дерзко, так как искренне не понимаю, зачем под статьей, которая вам не полезна писать такой длинный и едкий комментарий. Меня он очень расстроил.venanen
00.00.0000 00:00+1Полно Вам, если от комментариев расстраиваться - нервов не наберешься.
Комментарий не едкий, и не про Ваш пост в частности, а про ретро в целом, и вполне себе с аргументами.
Дело тут вот в чем: Вы имеете полное право проводить встречи в абсолютно любых форматах, хоть песни петь, если команда это поддерживает и это сказывается на атмосфере и результатах работы. Но есть нюанс: я это написал для читающих, чтобы не было впечатления того, это маст-хев практика, и надо срочно ее в продакшн. Почему? Потому что я в своей жизни видел немалое количество людей, которые без понимания инструмента/метода срочно вносят его в жизнь. Менеджеры, в частности, особенно. Иными словами случается вот что: к вам приходят и говорят, что "все, я прочитала новую крутую практику, с пятницы внедряем". На вопрос "зачем?" ответ обычно в стили "у всех есть, и у нас будет". И потом команда тратит 2 часа, и не очень понимает зачем. А самое главное - не понимает и менеджер, вроде стикеры лепятся, а сториков столько же за спринт закрываем. А ведь первое правило работы с техническим специалистом: "Как улучшить рабочий процесс спеца? Просто не мешай".
Плюс к этому, еще небольшое дополнение: ваши доводы действительно смотрятся хорошо, атмосфера, команда и так далее, но опять же, мы ведь взрослые люди. Если в команде люди плохо понимают друг друга на созвонах, или не способны самоорганизовываться для решения проблем и им нужно дополнительное совещание с викторинами - проблема все-таки не в ретро, а в команде, и решаться это должно через лида и как можно раньше.
Но, кстати, я после вашей статьи поговорил еще раз с людьми, и я могу вот что сказать: ретро это полезно, не всегда, но полезно. Только речь не о викторинах и поговорить (поговорить с командой это тоже позитивно, не может быть обязательным действием) - там речь о закрытии спринта. Если задачи систематически вылезают за спринт, косяки со временем, или просто скоро грядет жесткий релиз - очень полезно собраться в конце спринта и обсудить, в чем были косяки. Определяются сложности и пути их решения - по взрослому, и это очень помогает наладить работу. Тогда я ничего против не имею, это очень позитивно. Но, опять таки, лично я такого ретро не видел не разу, каждый раз в разных командах они все как один похожи на предыдущий мой комментарий.
Резюмируя: ретро не плохо, если вы четко знаете зачем и как это поможет и если для этого совещания есть предпосылки. В иных случаях, если ретро нужно потому что оно есть и у всех, и вообще скрам во все поля, то это скатывается к безумию.
P.S. Еще раз - я никого не хотел расстраивать.KaterinaTz Автор
00.00.0000 00:00Благодарю за ответ! Мир:)
Согласна с Вами, что в первую очередь нужно понимать ситуацию и использовать подходящий для нее инструмент.
ValeryGL
00.00.0000 00:00+1Про п.1-3. Люто соглашусь, но не на 100%.
Взрослые серьезные люди знают, что раз в две недели у них есть выделенные два часа, когда они могут поговорить и обсудить. Такая организованность настраивает. И снижает риск замалчивания, когда человек попытается сам разобраться и … и бросит, потому что так ему ещё потом нужно будет кого-то организовывать для обсуждения и решения.
И вот взрослые серьезные люди в течение спринта или двух в курилках или самостоятельно подумывают о найденной проблеме, самостоятельно или с кем-то накидывают варианты и копают причины. Зная, что потом будет (гарантированно будет! Этот слот не займут под текучку) время эти идеи рассказать, обсудить и возможно что-то решить.
Кажется, это работает
ValeryGL
00.00.0000 00:00Да, а про п.5, колеса фортуны и пр. - да, это выглядит как анимация в детском саду, испанский стыд, но эти чуднЫе техники фасилитация б.. работают! И интроверты разговаривают, сначала про кошек, потом про процессы.
GrishinAlex
00.00.0000 00:00Екатерина, спасибо за годную статью. Возьму ваши примеры на вооружение.
Я как раз сейчас искал чужой опыт проведение ретро на удаленке, но в русскоязычном сегменте интернета это оказалось нетривиальной задачей. В общем спасибо!
botyaslonim
00.00.0000 00:00Провожу ретро, длительность не более 15 минут. Каждый может высказаться, что было хорошего и плохого, я как тимлид говорю всегда последний. Записываем результаты в общедоступный список, каждый потом может посмотреть.
Все эти поля чудес и прочие геймификации считаю излишними и даже вредными. Люди любят играть тогда, когда они хотят, а не когда решило начальство. И золотое правило - не отнимать на болтовню много времени
reinmaker1990
00.00.0000 00:00Екатерина, отличная статья и опыт, забавным кажется нюанс, что статью по people managment пишет product manager, а не project manager, team lead, scrum master ????
Откуда столько времени, ведь каждая ретроспектива может занимать очень много времени, что для product'а кажется непозволительной роскошью.
TheN0rd
00.00.0000 00:00Мы проводим ретро в различных командах, в том числе и с численностью 15-20 человек, укладываемся в полтора часа вместе с разминкой и хелф чеком. Но мы проводим не на ручных досках (мира, фигма), а на платформе https://retrius.ru либо https://teamretro.com, там за счет автоматизации процесса вся команда можно сказать работает в более ускоренном режиме.
lymes
так оно и есть. отстаньте уже от девелоперов и проводите эти ваши полезнейшие скрам-ритуалы между собой.
KaterinaTz Автор
Привет! Хочу уточнить, ты опытный тимлид/менеджер или разработчик?
lymes
затрудняюсь ответить однозначно. как assoc manager я веду три проекта, на одном я просто занимаюсь governance и связью с клиентом, на втором я архитектор и тимлид, на третьем я просто иногда беру сложные и интересные таски если такие есть в спринте и пишу код, просто потому что проект интересный.
KaterinaTz Автор
Мне было горько читать твой комментарий под своей статьей. Я готовила ее, чтобы помочь другим менеджерам/тимлидам разнообразить будни разработки. Могу собрать информацию из источников и написать подробный ответ про пользу ретроспектив, если тебе интересно.
lymes
Да не вопрос. Для создания комфортной атмосферы в команде разработчиков просто дайте им время для работы, так как слишком много времени уходит на болтовню. Особенно если у вас короткие спринты 7-10 дней и большие числа в сторипойнтс. ИМХО, ретроспектива нужна если вы вдруг видите, что в последних двух-трех (не меньше) спринтах велосити команды почему-то упала, и надо бы понять в чем дело. А если все идет хорошо зачем людей этой тягомотиной мучать. Созвоны ради созвонов раздражают всех, просто помните это.