Комментарии 39
Бытует мнение, что ретроспектива это скучная встреча без явной пользы
так оно и есть. отстаньте уже от девелоперов и проводите эти ваши полезнейшие скрам-ритуалы между собой.
Привет! Хочу уточнить, ты опытный тимлид/менеджер или разработчик?
затрудняюсь ответить однозначно. как assoc manager я веду три проекта, на одном я просто занимаюсь governance и связью с клиентом, на втором я архитектор и тимлид, на третьем я просто иногда беру сложные и интересные таски если такие есть в спринте и пишу код, просто потому что проект интересный.
Мне было горько читать твой комментарий под своей статьей. Я готовила ее, чтобы помочь другим менеджерам/тимлидам разнообразить будни разработки. Могу собрать информацию из источников и написать подробный ответ про пользу ретроспектив, если тебе интересно.
Да не вопрос. Для создания комфортной атмосферы в команде разработчиков просто дайте им время для работы, так как слишком много времени уходит на болтовню. Особенно если у вас короткие спринты 7-10 дней и большие числа в сторипойнтс. ИМХО, ретроспектива нужна если вы вдруг видите, что в последних двух-трех (не меньше) спринтах велосити команды почему-то упала, и надо бы понять в чем дело. А если все идет хорошо зачем людей этой тягомотиной мучать. Созвоны ради созвонов раздражают всех, просто помните это.
А не пробовали с разработчиками как со взрослыми людьми поговорить о процессах, об улучшениях, и т.д.? Я скажу вообще крамольную вещь — в развитой команде не надо ждать две недели до ретро чтобы поднять вопрос, если с процессом что-то не так… На ретро есть смысл уже конкретно воркшопить варианты решений.
В общем, в таком виде — ретро мне начинает напоминать карго-культ. :-( Хорошо что у нас в компании подобным не страдают.
Согласно моим представлениям, разработчики все недалеко ушли от студентов )) на самом деле, и во взрослых коллективах многие предпочитают молча терпеть несовершенства, особенно если в целом атмосфера в фирме не располагает... а еще очень многие объективную критику воспринимают как личную обиду. Тут ко всем нужен свой подход)
Простой — устроить геймификацию, налепить виртуальных цветных бумажек и проч. Невозможно на уровне цветных бумажек обсуждать реально сложные проблемы разработки и находить хорошие решения.
И последнее — если вы относитесь к разработчикам как к детям — они рано или поздно и ведут себя как дети. Потом начнутся проблемы с контролем: без внешнего контроля дети в школу не ходят и домашку не делают. В конце-концов, получается команда которая без постоянного «искусственного дыхания» со стороны менеджмента и скрам-мастера не может существовать. И зачем оно такое ?!
Если вы считаете, что я отношусь к разработчикам, как к детям. Вы не правы. Чем вам помешали цветные стикеры, тоже не понимаю. Мне кажется, что онлайн-доски для совместной работы при большой удаленной команде крайне удобный инструмент, визуализиюрующий идею говорящего. Рост бизнеса Miro, FigJam и других инструментов тому свидетельство.
В любом случае, спасибо за большой подробный комментарий.
Буду благодарна, если опишешь подробнее, как вы проводите ретроспективу. Делитесь эмоциями или только решения задач разработки обсуждаете?
Вообще, ретро проходят по-разному, но к ним обязательно готовятся. Во-первых, там есть работа скрам-мастера, который отслеживает всякие метрики, обсуждает их с PO и Governance — и за которые у команды голова не болит каждый день. Чтобы не было искушения править метрики — SM обязан их интерпретировать, чтобы представить команде возможные проблемы и тренды, а не просто числа.
Дальше, есть обязательные топики — если, например, был инцидент на продакшене — ну значит стандартный воркшоп: как справились, где была root cause, что будем делать чтобы так больше не было. Если есть какие-то нехорошие ощущения у SM по поводу общения со стейкхолдерами и статистикой — ну значит вот это. Если кто-то из команды хочет что-то вынести на Retro — значит скрам-мастер будет с ним работать еще и 1-1 для подготовки информации. Плюс у нас принято, что все нововведения надо сначала проверить «на кошках». Например, выявили что у нас возникает проблема с параллельным выполнением задач из-за PR — придумали модификацию branch/merge стратегии. Ее не будут раскатывать сразу на всех — обычно есть инициативная группа добровольцев, которая будет ее на своих тасках использовать (возможно, дорабатывать). На ретро они расскажут свои ощущения от изменений — что хорошо, что плохо: дальше команда решит — раскатывать это дальше на всех, или пробовать что-то другое. Иногда по итогам ретро создаются рабочие группы добровольцев что-то посмотреть или почитать, чтобы не нагружать этим каждого девелопера в отдельности… Короче, все довольно плотно происходит — и не скучно, ну просто потому что обсуждаются и решаются реальные проблемы.
Я думаю, что пассивность на ретро — это во многом следствие ориентации команд на иерархию или незрелость. Либо команда не берет на себя обязанность организовать свою деятельность, ожидая что это будет делать менеджер, PO, техлид, тимлид и зеленые человечки с марса — либо просто не умеет это делать (например, если набрать в команду джунов — они настолько упахаются в кодинге в попытках исполнить обязательства — что на «подумать над процессом» у них уже ни сил, ни времени не останется). У нас на проекте приличное количество сеньоров и мидлов, а джун-подмастерье только один, и он далеко :-) Поэтому обычно по любому вопросу есть две-три разумные точки зрения. И дальше надо чтобы все эти безусловно умные, интеллигентные и убежденные в своей правоте люди — друг-друга не поубивали… А для этого надо синхронизироваться. Как-то так.
Добрый вечер! Спасибо, что описал формат вашего ретро! Ты первый, кто не только кляксу под статьей поставил, но и обозначил альтернативный вариант ретроспективы. Мне понравились практики разбирать инциденты и готовить с разработчиками тезисы для ретро заранее.
Наши команды разработки проводят действия, о которых ты пишешь. Например, инцидент на проде обычно разбирают на следующий день всей командой. До ретро не ждут. Ретроспектива же в командах направлена на общение и взаимодействие всей команды, всей группы.
Я не до конца понимаю такую многочисленную и объемную критику под своей статьей. Я описала ряд практик, которые помогают нашим командам хорошо работать. Тим лиды считают их полезными, разработчикам тоже нравится. Если они будут кому-то еще полезны, я буду танцевать. Если нет, то это меня мало касается.
Кстати, несколько менеджеров писали на linkedin, что попробуют использовать мои форматы в работе. Надеваю танцевальные туфли :)
В общем, это живая иллюстрация к тому, насколько плохо понимается и внедряется аджайл в разработке (и в бизнесе вообще). Соответственно, там где произошел сдвиг парадигмы в умах руководителей и оно внедряется не в виде ритуалов, а в виде бизнес-практик — таких отрицательных отзывов нет: все видят зачем это, и какие от этого получаются результаты.
Хочу подсветить, что мы проводим разные ретро. Форматы меняем в зависимости от настроения группы и нужды обсудить какую-то тему. На этой неделе в четверг и пятницу проводили ретро про завершенные большие проекты. Было поле для описания положительного опыта и негативного опыта, при работе над конкретным проектом.
Ну, иногда это единственный вариант получить обратную связь. Стадный инстинкт работает даже для интовёртов, в личном разговоре он закроется, а на этом несерьезном совещании может и рассказать что нибудь полезное. То же для юниоров, они часто боятся рассказывать о проблемах один на один. А тут - все говорят, значит и я скажу.
Рассматривайте ретроспективу как вариант тим билдинга, возможность узнать немного больше о команде, а не как единственное место для улучшения рабочих процессов.
Для молодой компании, которая полностью на дистанционном, полезные практики! Спасибо за материал, заберу себе)
Сколько не было в моей жизни ретроспектив - я так и не понял, зачем, а главное нафига просто взять, и оттяпать 2 часа рабочего времени на что-то, похожее на детский утренник с серьезными словами. Нет, я все понимаю, есть какая-то крайне мало поддающаяся моему уму практика - устроить из любой вещи дичь, которая никому не нужна. Хороводы, падения на доверия, викторины, и прочий тимбилдинг имеющий тонкий привкус менеджерского безумия и явный и отчетливый запах испанского стыда. Но:
1) Мы тут вообще-то работаем, мы тут так-то взрослые, серьезные люди, и если у кого-то возникает проблема, он берет и сообщает о ней. Заранее, сразу, и не ждет 2 недели до ближайшего ретро, чтобы прилепить стикер;
2) Если в команде есть проблема, которая замалчивается по каким-то причинам - нет ровно ни одной причины, почему разработчик молчал, а теперь должен публично ее объявить;
3) Стикеры - это мое любимое. Дело в том, что сколько я бывал в командах, в результате взаимодействий команды все вопросы были решены, или было постулировано, что решение не найдено, и это задолго до ретроспективы. Но на ретро тебе говорят: придумай проблемы. И их реально сидят и придумывают и лепят стикеры, вместо того, чтобы решать единственную проблему - допилить все к релизу. Похоже на какой-то очень специфический KPI;
4) Эффекта я не видел ни разу. И никто из моих знакомых не видел. Ну, кроме того, что стикеры прилеплены - это да, а решений нет - потому что сложно решить проблемы, которой нет, которую вы придумали полчаса назад. А это еще и идет долго, если посчитать, сколько стоит бизнесу это развлечение - можно упасть со стула;
5) Все эти колеса фортуны, викторины, попытка втянуть каждого в разговор - это само по себе глупо, потому что среди разработчиков очень немало интровертов, и они разговаривать о 5 видах кошек, которых он видел на даче не особо хочется. Лучший результат который я видел - это когда в офис привезли пиццу - за пиццой и пивом разговор отлично клеится.
При этом стоит отметить, что те-же дейлики, или звонки с профильными командами - это очень позитивная практика. Полчаса делов и все по делу. А ретро - это что-то очень странное.
Привет! Спасибо за комментарий! Мне не совсем понятна его цель. Я описала в статье пользу от ретроспектив, которые я провожу.
задействованы все члены команды;
атмосфера способствует открытому общению;
становится легче разговаривать и понимать друг друга на созвонах;
появляется ощущение коллектива и командной работы.
Ее видят тим лиды и члены команды, с которыми я работаю. Если вы ее не видите, не используйте данные форматы.
Пиццу я тоже люблю. Только сейчас мы работаем на удаленке в разных городах и странах.
Поясню свой комментарий "Если вы ее не видите, не используйте данные форматы."
Цель моей статьи - обогатить русский дискурс статьей про идеи ретроспектив. Когда я искала сама статьи на русском про ретроспективы, то ничего толкового не нашла. На английском подобных статей с идеями для ретро множество. Я не готова убеждать, что наши ретро полезны и их должны все проводить. У каждого своя команда и своя ситуация. Если вы бы были в поиске идеи для ретро, вы могли попробовать воспользоваться моими. Если нет, и у вас все хорошо с ретрами или без них, то вам они не нужны.
Я ответила достаточно дерзко, так как искренне не понимаю, зачем под статьей, которая вам не полезна писать такой длинный и едкий комментарий. Меня он очень расстроил.
Полно Вам, если от комментариев расстраиваться - нервов не наберешься.
Комментарий не едкий, и не про Ваш пост в частности, а про ретро в целом, и вполне себе с аргументами.
Дело тут вот в чем: Вы имеете полное право проводить встречи в абсолютно любых форматах, хоть песни петь, если команда это поддерживает и это сказывается на атмосфере и результатах работы. Но есть нюанс: я это написал для читающих, чтобы не было впечатления того, это маст-хев практика, и надо срочно ее в продакшн. Почему? Потому что я в своей жизни видел немалое количество людей, которые без понимания инструмента/метода срочно вносят его в жизнь. Менеджеры, в частности, особенно. Иными словами случается вот что: к вам приходят и говорят, что "все, я прочитала новую крутую практику, с пятницы внедряем". На вопрос "зачем?" ответ обычно в стили "у всех есть, и у нас будет". И потом команда тратит 2 часа, и не очень понимает зачем. А самое главное - не понимает и менеджер, вроде стикеры лепятся, а сториков столько же за спринт закрываем. А ведь первое правило работы с техническим специалистом: "Как улучшить рабочий процесс спеца? Просто не мешай".
Плюс к этому, еще небольшое дополнение: ваши доводы действительно смотрятся хорошо, атмосфера, команда и так далее, но опять же, мы ведь взрослые люди. Если в команде люди плохо понимают друг друга на созвонах, или не способны самоорганизовываться для решения проблем и им нужно дополнительное совещание с викторинами - проблема все-таки не в ретро, а в команде, и решаться это должно через лида и как можно раньше.
Но, кстати, я после вашей статьи поговорил еще раз с людьми, и я могу вот что сказать: ретро это полезно, не всегда, но полезно. Только речь не о викторинах и поговорить (поговорить с командой это тоже позитивно, не может быть обязательным действием) - там речь о закрытии спринта. Если задачи систематически вылезают за спринт, косяки со временем, или просто скоро грядет жесткий релиз - очень полезно собраться в конце спринта и обсудить, в чем были косяки. Определяются сложности и пути их решения - по взрослому, и это очень помогает наладить работу. Тогда я ничего против не имею, это очень позитивно. Но, опять таки, лично я такого ретро не видел не разу, каждый раз в разных командах они все как один похожи на предыдущий мой комментарий.
Резюмируя: ретро не плохо, если вы четко знаете зачем и как это поможет и если для этого совещания есть предпосылки. В иных случаях, если ретро нужно потому что оно есть и у всех, и вообще скрам во все поля, то это скатывается к безумию.
P.S. Еще раз - я никого не хотел расстраивать.
Про п.1-3. Люто соглашусь, но не на 100%.
Взрослые серьезные люди знают, что раз в две недели у них есть выделенные два часа, когда они могут поговорить и обсудить. Такая организованность настраивает. И снижает риск замалчивания, когда человек попытается сам разобраться и … и бросит, потому что так ему ещё потом нужно будет кого-то организовывать для обсуждения и решения.
И вот взрослые серьезные люди в течение спринта или двух в курилках или самостоятельно подумывают о найденной проблеме, самостоятельно или с кем-то накидывают варианты и копают причины. Зная, что потом будет (гарантированно будет! Этот слот не займут под текучку) время эти идеи рассказать, обсудить и возможно что-то решить.
Кажется, это работает
Да, а про п.5, колеса фортуны и пр. - да, это выглядит как анимация в детском саду, испанский стыд, но эти чуднЫе техники фасилитация б.. работают! И интроверты разговаривают, сначала про кошек, потом про процессы.
Екатерина, спасибо за годную статью. Возьму ваши примеры на вооружение.
Я как раз сейчас искал чужой опыт проведение ретро на удаленке, но в русскоязычном сегменте интернета это оказалось нетривиальной задачей. В общем спасибо!
Провожу ретро, длительность не более 15 минут. Каждый может высказаться, что было хорошего и плохого, я как тимлид говорю всегда последний. Записываем результаты в общедоступный список, каждый потом может посмотреть.
Все эти поля чудес и прочие геймификации считаю излишними и даже вредными. Люди любят играть тогда, когда они хотят, а не когда решило начальство. И золотое правило - не отнимать на болтовню много времени
Екатерина, отличная статья и опыт, забавным кажется нюанс, что статью по people managment пишет product manager, а не project manager, team lead, scrum master 😀
Откуда столько времени, ведь каждая ретроспектива может занимать очень много времени, что для product'а кажется непозволительной роскошью.
Отличное замечание. Даже не знаю, как оправдаться. Отвечу, как есть. У меня смешанная роль. Кто-то между product manager/ project manager / scrum master. Я забочусь о продукте и о командах, которые за него отвечают. У меня горело проводить насыщенные активные ретроспективы, поэтому я взяла их в свои руки у тех лидов. Время находится, так как видна польза для команд.
Мы проводим ретро в различных командах, в том числе и с численностью 15-20 человек, укладываемся в полтора часа вместе с разминкой и хелф чеком. Но мы проводим не на ручных досках (мира, фигма), а на платформе https://retrius.ru либо https://teamretro.com, там за счет автоматизации процесса вся команда можно сказать работает в более ускоренном режиме.
Бытует мнение, что ретроспектива это скучная встреча без явной пользы.
Кажется, всё ровно наоборот: ретро, наверное, самый важный и мощный из всем известных командных ритуалов. Это долгосрочная инвестиция в продуктивность команды. Без поиска узких мест и постоянных улучшений, сложно добиться успеха.
Как было правильно написано, очень важна подготовка, а особенно - понимание, какие проблемы нужно решить в команде. А также выполнимый план по конкретным улучшениям на выходе и готовность его претворить в жизнь.
На у техники проведения ... это хорошо, что их много: можно выбрать те, которые выстрелят в конкретной команде. Пару новых почерпнул, спасибо.
Привет, Сергей! Спасибо за обратную связь. Абсолютно согласна, что техник много и для каждой команды и ситуации подходят свои. Я описала в статье оригинальные идеи для большой команды. Мы с командами в последнее время проводили совсем другие форматы. Были темы, по которым нужно было провести брейншторм, договориться о решении со всей командой.
Вспомнить всё: проводим ретроспективы для удалённых команд