Недавно я подсчитала, что за несколько лет работы в роли Скрам Мастера я провела более 100 ретроспектив в Agile-командах. О важности ретроспективы и том, как она отражает ситуацию в команде и влияет на ее развитие, хочу поговорить в этой статье.
Пару слов обо мне. С 2015 года я фокусно работаю над построением счастливых и эффективных Agile-команд в международных компаниях. Кроме того, мне нравится заниматься внутренним обучением. Помимо основной работы с командой я преподаю в школе Скрам Мастеров и провожу тренинги по направлениям Agile/Scrum/Agile testing.
С момента начала моей карьеры в роли Скрам Мастера, мне посчастливилось напрямую поработать с 10 очень разными и интересными командами. Каждая из них развивалась в своем уникальном темпе и все же было у них нечто общее — качество проведения ретроспектив сильно влияло на общую эффективность команды. При этом я заметила, что в любой команде ретроспектива рано или поздно перестает работать. Что-то происходит и этот самый популярный инструмент Инспекции и Адаптации ломается, т.е. перестает помогать команде адаптироваться и совершенствоваться.
Я систематизировала свои наблюдения и хотела бы поделиться 5 основными антипаттернами, которые я встречала в своих командах.
В рамках каждого антипаттерна хочу обсудить:
В первой части статьи я расскажу о трех антипаттернах. Во второй части – поделюсь наблюдениями о двух других антипаттернах, а также своими рекомендациями: что могут сделать Скрам Мастера и команды превентивно, т.е. заранее, еще до появления описанного в статье поведения, чтобы ретроспектива продолжала работать и быть эффективным инструментом для улучшений в команде.
Команда ретроспективу проводит, но считает это формальностью. Антипаттерн проявляется в том, что команда в принципе решает ретроспективу не проводить (нет проблем, все хорошо – зачем собираться?). Но на моей практике этот случай встречался крайне редко и отказ от ретроспективы диктовался скорее другими причинами. О них я потом напишу отдельную статью. А пока вернемся к тому, как распознать этот антипаттерн.
Признаки и причины:
Команда собирается, открывает стандартный шаблон активности на ретроспективе (mad/sad/glad или start/stop/continue), записывает основные положительные моменты прошедшей итерации и через 20-30 минут расходится без обсуждения проблем и плана улучшений в команде. Команда либо избегает говорить о проблемах, либо убеждает Скрам Мастера и друг друга, что улучшаться уже просто некуда.
В чем может быть причина такого поведения?
Что делать:
В этой истории для меня многое зависит от того, насколько я, как Скрам Мастер, верю, что в команде все хорошо, или же у меня есть в этом сомнения.
Если есть ощущение, что в команде действительно все идет замечательно, можно действовать следующим образом:
— Предложить команде на ретроспективе сложный, выводящий из зоны комфорта вопрос. Например, «что мы, как команда, можем придумать, чтобы поставлять в 10 раз больше функциональности, чем сейчас, за то же время». Или «как можно полностью уйти от ручного прогона регрессии». Для некоторых моих команд второй вопрос звучал еще более неадекватным, чем первый.
Первая реакция на этот вопрос скорее всего будет ступор и удивление, но следующим шагом может стать интересный мозговой штурм, взгляд на систему в целом и интересные идеи оптимизации всего процесса поставки ценности.
— Воспользоваться возможностью членам команды узнать друг друга еще лучше и прокачать командную работу с помощью игр. Я не буду подробно останавливаться на теме игр, скажу лишь, что есть замечательные активности на работу с ценностями Скрама, для построения фокуса на общей цели, на построение доверия в команде. В открытых источниках есть множество описанных форматов игр. О тех, которые проводила я, делюсь у себя в профессиональном блоге Скрам Мастера.
Конечно, играми не стоит полностью заменять ретроспективы, но они могут стать «передышкой» для команды, возможностью сменить рабочий контекст и посмотреть на эффективность командной работы с другой стороны.
И все-таки, что делать Скрам Мастеру, если нет этой внутренней уверенности, что все хорошо? На этот случай у меня есть две идеи.
Первая – это расширить контекст ретроспективы для команды, т.е. расширить угол зрения на ситуацию в команде. Например, этого можно добиться добавлением на ретроспективу новых участников. Я видела много команд, которые проводили ретроспективы без участия владельца продукта в силу разных обстоятельств (он не хотел, так исторически сложилось, языковой барьер). Для таких команд ретроспектива с участием владельца продукта пройдет совершенно по-новому. Эту же идею можно реализовать, пригласив членов других смежных команд, которые стоят впереди или после команды в цепочке поставки ценности. Одна важная деталь – все это необходимо делать с согласия команды, приглашенный гость в качестве сюрприза скорее принесет боль и недоверие к Скрам Мастеру, чем поможет наладить ретроспективу.
Вторая идея – Скрам Мастеру или кому-то из членов команды предложить собрать данные, которые раньше никогда не собирали. У меня в опыте есть замечательный пример, когда анализ собранной статистики о количестве заведенных дефектов внутри спринта (а именно тренд этой метрики за 4 прошедших спринта), привел команду к очень продуктивным обсуждениям, как повысить качество тестирования у разработчиков и как организовать тесное взаимодействие тестирования и разработки внутри спринта. Зачастую случается так, что в целом команда отлично справляется и по своим ощущениям, и по обратной связи снаружи, но есть еще много моментов для улучшения, нужно просто обратить на них внимание команды.
История о том, что команда с готовностью приходит на ретроспективу жаловаться, возмущаться, горевать, ныть, но плана работы с проблемами, как и плана улучшений, в результате ретроспективы нет. Точнее, план у команды есть, набор действий составлен, есть ответственные, но этот план не помогает команде реально улучшаться, не помогает ставить эксперименты и проверять гипотезы с целью повышения эффективности работы или повышения качества продукта. Этот план скорее формальность, план ради плана.
Признаки:
Давайте рассмотрим, как можно работать с этими ситуациями.
Что делать:
Начнем по порядку. Чтобы в команде мог появиться план улучшений, прежде всего, нужно, чтобы повестка ретроспективы (а именно все ее фазы – регистрация, сбор идей, анализ идей, составление плана улучшений, завершение и обратная связь) была прозрачна команде, и в ней оставалось время на составление плана дальнейших действий. У меня были случаи, когда мы не успевали глубоко проработать план действий и тогда я назначала отдельную сессию, чтобы закончить ретроспективу и сформировать план. Я считаю, что лучше расширить выделенное на ретроспективу время, чем закончить вовремя, но выйти без результатов.
Если в команде проблемы с тем, чтобы укладываться в запланированное время встречи, есть подход установки нескольких таймеров, например, на 15, 8 и 5 минут. С самого начала команда знает, что обсуждение должно закончиться к концу третьего таймера и больше сфокусирована на том, чтобы договориться. Вообще техники фасилитации, организация работы в малых группах и фиксированное время на для обсуждений и отдельных фаз ретроспективы творят чудеса и помогают приводить к выработке решений даже группы со сложной динамикой.
Что же делать Скрам Мастеру, если команда приносит на ретроспективу в основном организационные темы и избегает реальных проблем? Есть несколько инструментов, которые по моему опыту помогали:
Название говорит само за себя – у команды был составлен план, но придуманные действия или эксперименты не выполняются.
Признаки:
Признаки антипаттерна достаточно очевидные – на следующей ретроспективе команде нечем поделиться в качестве результатов выполнения придуманных ранее действий или договоренностей. У всех, конечно, есть уважительные причины – не успел, руки не дошли, занимался более важными делами, забыл. Но в результате продвижения в плане улучшений и экспериментов нет.
Говоря про этот антипаттерн, я хочу подробнее остановиться на «тревожных звоночках» на этапе составления плана, которые на моей практике чаще всего были сигналами, что действия из плана выполняться не будут:
Что я делаю в ситуации, когда в моей команде появляются планы, которые пишутся, но не делаются? Я вспоминаю о том, что если люди чего-то не делают, на это могут быть следующие причины:
1. Не понял
2. Не могу
3. Не умею
4. Не хочу
Мне эта мысль сильно помогает остановиться и подумать, можно ли исключить варианты «не понял, не могу, не умею», прежде чем начинать работать в области «не хочу» и разбираться с мотивацией человека, зачем он в команде и какие у него цели.
Что делать?
Давайте посмотрим, что конкретно можно сделать, в зависимости от того, в чем есть причина бездействия.
Причина 1: член команды, который согласился взять на себя какой-то action item действительно не понял, что от него ожидается.
Причина 2: член команды и рад бы выполнить тот action item, что взял на себя, но физически не может этого сделать, т.к. занят другими задачами и у него нет на это времени в спринте.
Скрам Мастер может добавить самую главную активность из плана с ретроспективы в бэклог спринта (согласовав это с владельцем продукта на ретро или после), оценить ее, отметить, кто именно ей будет заниматься, сделать прозрачным для всех, что команда будет тратить на это время.
Причина 3: член команды вновь был бы рад выполнить то, на что подписался, потому что ему это правда интересно и важно (например, выбрать наиболее подходящий фреймворк для нагрузочного тестирования), да вот только он никогда с этим раньше дело не имел и никак не может понять, с чего начать. На этом он и заканчивает, так как может быть неприятно объяснить команде, зачем же он взял эту активность, если не умеет.
Скрам Мастер может уточнять у того, кто готов взять на себя активность в рамках плана ретро, приходилось ли ему делать что-то подобное раньше. Если нет, наверняка в команде есть кто-то более опытный в этом вопросе, кто смог бы помочь. А если у всей команды нет экспертизы в области, Скрам Мастер может взять на себя задачу поискать экспертов в других командах или сообществе.
Есть у меня еще одна бонусная практика, которая реально помогает команде выполнять план – повесить активности из плана на видное место для команды. В идеале каждый член команды, который взял какую-то активность, унес с собой стикер с этим TO DO, чтобы повесить на видное место у рабочего стола и не забывать о нем. Говорят, если цель перед глазами, человек сознательно и бессознательно к ней идет. Такой подход мне нравится значительно больше, чем регулярно напоминать команде о том, что близится ретро и стоит освежить в памяти, в чем состоял план прошлый раз.
Итак, я поделилась мыслями о первых трех антипаттернах ретроспективы в Agile командах, с которыми встречалась в своей практике, а впереди еще два, не менее интересных и не менее часто встречающихся антипаттерна.
Буду рада вашим историям и наблюдениям о ретроспективах, которые работают и которые нет. Расскажите, какие у вас есть техники и приемы построения эффективных ретроспектив. Вы догадываетесь, о каких двух антипаттернах я планирую рассказать в продолжении?
Пару слов обо мне. С 2015 года я фокусно работаю над построением счастливых и эффективных Agile-команд в международных компаниях. Кроме того, мне нравится заниматься внутренним обучением. Помимо основной работы с командой я преподаю в школе Скрам Мастеров и провожу тренинги по направлениям Agile/Scrum/Agile testing.
С момента начала моей карьеры в роли Скрам Мастера, мне посчастливилось напрямую поработать с 10 очень разными и интересными командами. Каждая из них развивалась в своем уникальном темпе и все же было у них нечто общее — качество проведения ретроспектив сильно влияло на общую эффективность команды. При этом я заметила, что в любой команде ретроспектива рано или поздно перестает работать. Что-то происходит и этот самый популярный инструмент Инспекции и Адаптации ломается, т.е. перестает помогать команде адаптироваться и совершенствоваться.
Я систематизировала свои наблюдения и хотела бы поделиться 5 основными антипаттернами, которые я встречала в своих командах.
В рамках каждого антипаттерна хочу обсудить:
- признаки и причины появления определенного поведения;
- что предпринять Скрам Мастеру и команде для исправления ситуации.
В первой части статьи я расскажу о трех антипаттернах. Во второй части – поделюсь наблюдениями о двух других антипаттернах, а также своими рекомендациями: что могут сделать Скрам Мастера и команды превентивно, т.е. заранее, еще до появления описанного в статье поведения, чтобы ретроспектива продолжала работать и быть эффективным инструментом для улучшений в команде.
Антипаттерн № 1 «У нас все хорошо»
Команда ретроспективу проводит, но считает это формальностью. Антипаттерн проявляется в том, что команда в принципе решает ретроспективу не проводить (нет проблем, все хорошо – зачем собираться?). Но на моей практике этот случай встречался крайне редко и отказ от ретроспективы диктовался скорее другими причинами. О них я потом напишу отдельную статью. А пока вернемся к тому, как распознать этот антипаттерн.
Признаки и причины:
Команда собирается, открывает стандартный шаблон активности на ретроспективе (mad/sad/glad или start/stop/continue), записывает основные положительные моменты прошедшей итерации и через 20-30 минут расходится без обсуждения проблем и плана улучшений в команде. Команда либо избегает говорить о проблемах, либо убеждает Скрам Мастера и друг друга, что улучшаться уже просто некуда.
В чем может быть причина такого поведения?
- Ребята могут искренне верить, что у них все хорошо: они поставляют продукт, владелец продукта доволен, что еще нужно?
- Это супер-слаженная команда, которая давно работает вместе и не может представить, как можно стать еще лучше, ведь на них и так все в компании равняются.
- Мне встречались команды, члены которых верили, что все существующие проблемы, которые были в зоне контроля или влияния команды уже исправлены, а с остальными проблемами команде все равно ничего не сделать, какой смысл тратить время и снова их обсуждать. Для таких проблем у меня даже термин появился – «корпоративная данность».
Что делать:
В этой истории для меня многое зависит от того, насколько я, как Скрам Мастер, верю, что в команде все хорошо, или же у меня есть в этом сомнения.
Если есть ощущение, что в команде действительно все идет замечательно, можно действовать следующим образом:
— Предложить команде на ретроспективе сложный, выводящий из зоны комфорта вопрос. Например, «что мы, как команда, можем придумать, чтобы поставлять в 10 раз больше функциональности, чем сейчас, за то же время». Или «как можно полностью уйти от ручного прогона регрессии». Для некоторых моих команд второй вопрос звучал еще более неадекватным, чем первый.
Первая реакция на этот вопрос скорее всего будет ступор и удивление, но следующим шагом может стать интересный мозговой штурм, взгляд на систему в целом и интересные идеи оптимизации всего процесса поставки ценности.
— Воспользоваться возможностью членам команды узнать друг друга еще лучше и прокачать командную работу с помощью игр. Я не буду подробно останавливаться на теме игр, скажу лишь, что есть замечательные активности на работу с ценностями Скрама, для построения фокуса на общей цели, на построение доверия в команде. В открытых источниках есть множество описанных форматов игр. О тех, которые проводила я, делюсь у себя в профессиональном блоге Скрам Мастера.
Конечно, играми не стоит полностью заменять ретроспективы, но они могут стать «передышкой» для команды, возможностью сменить рабочий контекст и посмотреть на эффективность командной работы с другой стороны.
И все-таки, что делать Скрам Мастеру, если нет этой внутренней уверенности, что все хорошо? На этот случай у меня есть две идеи.
Первая – это расширить контекст ретроспективы для команды, т.е. расширить угол зрения на ситуацию в команде. Например, этого можно добиться добавлением на ретроспективу новых участников. Я видела много команд, которые проводили ретроспективы без участия владельца продукта в силу разных обстоятельств (он не хотел, так исторически сложилось, языковой барьер). Для таких команд ретроспектива с участием владельца продукта пройдет совершенно по-новому. Эту же идею можно реализовать, пригласив членов других смежных команд, которые стоят впереди или после команды в цепочке поставки ценности. Одна важная деталь – все это необходимо делать с согласия команды, приглашенный гость в качестве сюрприза скорее принесет боль и недоверие к Скрам Мастеру, чем поможет наладить ретроспективу.
Вторая идея – Скрам Мастеру или кому-то из членов команды предложить собрать данные, которые раньше никогда не собирали. У меня в опыте есть замечательный пример, когда анализ собранной статистики о количестве заведенных дефектов внутри спринта (а именно тренд этой метрики за 4 прошедших спринта), привел команду к очень продуктивным обсуждениям, как повысить качество тестирования у разработчиков и как организовать тесное взаимодействие тестирования и разработки внутри спринта. Зачастую случается так, что в целом команда отлично справляется и по своим ощущениям, и по обратной связи снаружи, но есть еще много моментов для улучшения, нужно просто обратить на них внимание команды.
Антипаттерн №2 «Ноем, жалуемся, плана нет»
История о том, что команда с готовностью приходит на ретроспективу жаловаться, возмущаться, горевать, ныть, но плана работы с проблемами, как и плана улучшений, в результате ретроспективы нет. Точнее, план у команды есть, набор действий составлен, есть ответственные, но этот план не помогает команде реально улучшаться, не помогает ставить эксперименты и проверять гипотезы с целью повышения эффективности работы или повышения качества продукта. Этот план скорее формальность, план ради плана.
Признаки:
- Команда бурно обсуждает то, что происходит в команде, но достаточно времени на составление плана не остается, и она расходится до следующего раза, в лучшем случае, со списком того, с чем они когда-то потом планируют работать. Вопрос, кто именно, когда и как будет работать, остается открытым.
- Команда обсуждает проблемы, но приходит к тому, что они слишком сложные, как с ними справиться непонятно, и члены команды решают отложить их: возможно, проблемы решатся сами собой или кто-то другой придумает, как исправить ситуацию.
- Я лично была участником не одной ретроспективы, когда в конце встречи у команды формируются множество активностей для исполнения, но 80-90% из них связаны с организационными вопросами – например, как организовать пространство в комнате, какую мебель поставить, в каком месте хранить список активностей после ретро. Эти моменты тоже могут быть важны для команды и в том, что такие активности есть, нет проблемы. Проблема появляется тогда, когда кроме этих аспектов жизни команды другие моменты (качество продукта, зрелость технических практик, атмосфера в команде) в расчет не принимаются или рассматриваются вскользь, когда остается время после обсуждения насущных организационных вопросов.
Давайте рассмотрим, как можно работать с этими ситуациями.
Что делать:
Начнем по порядку. Чтобы в команде мог появиться план улучшений, прежде всего, нужно, чтобы повестка ретроспективы (а именно все ее фазы – регистрация, сбор идей, анализ идей, составление плана улучшений, завершение и обратная связь) была прозрачна команде, и в ней оставалось время на составление плана дальнейших действий. У меня были случаи, когда мы не успевали глубоко проработать план действий и тогда я назначала отдельную сессию, чтобы закончить ретроспективу и сформировать план. Я считаю, что лучше расширить выделенное на ретроспективу время, чем закончить вовремя, но выйти без результатов.
Если в команде проблемы с тем, чтобы укладываться в запланированное время встречи, есть подход установки нескольких таймеров, например, на 15, 8 и 5 минут. С самого начала команда знает, что обсуждение должно закончиться к концу третьего таймера и больше сфокусирована на том, чтобы договориться. Вообще техники фасилитации, организация работы в малых группах и фиксированное время на для обсуждений и отдельных фаз ретроспективы творят чудеса и помогают приводить к выработке решений даже группы со сложной динамикой.
Что же делать Скрам Мастеру, если команда приносит на ретроспективу в основном организационные темы и избегает реальных проблем? Есть несколько инструментов, которые по моему опыту помогали:
- Задавать команде структуру во время этапа сбора идей – спрашивать о разных аспектах жизни команды – процессах, качестве продукта, эффективности коммуникаций, вместо того, чтобы задавать вопросы общего характера «что было хорошо, что было плохо».
- Спрашивать в самом начале о чувствах, которые испытывали члены команды в течение спринта (например, построить линии эмоций по всем дням спринта для каждого члена команды). И дальше уточнять, что именно вызывало данные эмоции. Таким образом, можно определить важные проблемы, которые действительно волнуют членов команды.
- Анализировать, какие из перечисленных наблюдений, проблем, идей, названных командой на фазе сбора идей, действительно оказывают влияние на команду и на продукт. И приоритизировать идеи членов команды в зависимости от степени их влияния. Важно помнить, что всё сразу исправить невозможно, нужно выработать культуру работы с одной-двумя самыми важными проблемами или темами на текущий момент.
- Для тех случаев, когда организационных тем и вопросов очень много, можно договориться вести бэклог таких задач и выработать правила выставления им приоритетов, а также договориться, сколько команда может взять таких задач в работу в рамках спринта. Эх, как бы помогла мне эта практика на заре моей карьеры в роли Скрам Мастера!
Антипаттерн №3 «План есть, но мы ничего не делаем»
Название говорит само за себя – у команды был составлен план, но придуманные действия или эксперименты не выполняются.
Признаки:
Признаки антипаттерна достаточно очевидные – на следующей ретроспективе команде нечем поделиться в качестве результатов выполнения придуманных ранее действий или договоренностей. У всех, конечно, есть уважительные причины – не успел, руки не дошли, занимался более важными делами, забыл. Но в результате продвижения в плане улучшений и экспериментов нет.
Говоря про этот антипаттерн, я хочу подробнее остановиться на «тревожных звоночках» на этапе составления плана, которые на моей практике чаще всего были сигналами, что действия из плана выполняться не будут:
- В тексте наших action items (т.е. плана действий) много формулировок со словами «разобраться, решить, договориться». Скорее всего, это важные моменты, но они совершенно не конкретны.
- Мы записываем очень общие, плохо измеримые идеи, которые скорее похожи на лозунги. Из того, что я встречала в каждой второй своей команде, было «давайте писать больше unit тестов». Мы, как команда, формулируем полезные на первый взгляд действия, такие как «уделять больше внимания качеству», «организовать более тесное взаимодействие между членами команды», но глубже этих фраз мы не копаем, ответственными за эти лозунги становится вся команда. И что конкретно делать для обеспечения «лучше, больше, эффективнее» никто не знает.
- Я сразу вспоминаю об этом антипаттерне, когда слышу от членов команды такие фразы: «пишите, Светлана, пишите, в wiki много места, пусть будет», «скорее всего это нам не поможет/скорее всего, делать не будем, но давайте запишем», «о, это уже 3 раз, когда мы записываем этот поинт, может, на этот раз получится», «я уверен, что это ерунда, но раз вы хотите, давайте запишем»
Что я делаю в ситуации, когда в моей команде появляются планы, которые пишутся, но не делаются? Я вспоминаю о том, что если люди чего-то не делают, на это могут быть следующие причины:
1. Не понял
2. Не могу
3. Не умею
4. Не хочу
Мне эта мысль сильно помогает остановиться и подумать, можно ли исключить варианты «не понял, не могу, не умею», прежде чем начинать работать в области «не хочу» и разбираться с мотивацией человека, зачем он в команде и какие у него цели.
Что делать?
Давайте посмотрим, что конкретно можно сделать, в зависимости от того, в чем есть причина бездействия.
Причина 1: член команды, который согласился взять на себя какой-то action item действительно не понял, что от него ожидается.
- Скрам Мастер может убедиться, что для каждого элемента в списке нашего плана четко сформулирован первый шаг и даже в большой объемной задаче понятно с чего начать.
- Скрам Мастер может просить того, кто берет активность, сформулировать вслух, что именно он собирается делать и понятно ли, в чем идея активности.
- Скрам Мастер может лишний раз спросить у команды, всем ли понятно, что именно написано в плане, и есть ли какие-то вопросы.
Причина 2: член команды и рад бы выполнить тот action item, что взял на себя, но физически не может этого сделать, т.к. занят другими задачами и у него нет на это времени в спринте.
Скрам Мастер может добавить самую главную активность из плана с ретроспективы в бэклог спринта (согласовав это с владельцем продукта на ретро или после), оценить ее, отметить, кто именно ей будет заниматься, сделать прозрачным для всех, что команда будет тратить на это время.
Причина 3: член команды вновь был бы рад выполнить то, на что подписался, потому что ему это правда интересно и важно (например, выбрать наиболее подходящий фреймворк для нагрузочного тестирования), да вот только он никогда с этим раньше дело не имел и никак не может понять, с чего начать. На этом он и заканчивает, так как может быть неприятно объяснить команде, зачем же он взял эту активность, если не умеет.
Скрам Мастер может уточнять у того, кто готов взять на себя активность в рамках плана ретро, приходилось ли ему делать что-то подобное раньше. Если нет, наверняка в команде есть кто-то более опытный в этом вопросе, кто смог бы помочь. А если у всей команды нет экспертизы в области, Скрам Мастер может взять на себя задачу поискать экспертов в других командах или сообществе.
Есть у меня еще одна бонусная практика, которая реально помогает команде выполнять план – повесить активности из плана на видное место для команды. В идеале каждый член команды, который взял какую-то активность, унес с собой стикер с этим TO DO, чтобы повесить на видное место у рабочего стола и не забывать о нем. Говорят, если цель перед глазами, человек сознательно и бессознательно к ней идет. Такой подход мне нравится значительно больше, чем регулярно напоминать команде о том, что близится ретро и стоит освежить в памяти, в чем состоял план прошлый раз.
Итак, я поделилась мыслями о первых трех антипаттернах ретроспективы в Agile командах, с которыми встречалась в своей практике, а впереди еще два, не менее интересных и не менее часто встречающихся антипаттерна.
Буду рада вашим историям и наблюдениям о ретроспективах, которые работают и которые нет. Расскажите, какие у вас есть техники и приемы построения эффективных ретроспектив. Вы догадываетесь, о каких двух антипаттернах я планирую рассказать в продолжении?
