Что такое ретроспектива и как с ней работать, чтобы бэклог не стремился к бесконечности

Привет, меня зовут Алексей Маренич. Управление и ведение различных проектов — это то, чем я занимался, еще будучи студентом. Сейчас я менеджер проектов и скрам-лид в компании SoftServe Business Systems. Когда я начинал работать как скрам-мастер, были митинги, которые, как я оценивал, проходили успешно, некоторые менее успешно.

Наиболее сложной, на тот момент, мне казалась ретроспектива. Даже пройдя сертификацию и прочитав скрам-гайд, не очевидно, какие техники использовать и на что нужно обращать внимание, чтобы сделать этот митинг продуктивным, а не «еще одним митингом в календарях девелоперов с непонятной повесткой».

Данная статья, будет интересна скрам-мастерам, которые испытывают или испытывали такие же сложности, а также тем, кто интересуется фреймворком Scrum.

Иллюстрация Марии Рыбак

Что такое ретроспектива

«Ретроспектива Спринта — это возможность для Скрам‐команд исследовать себя и создать план улучшений для следующего Спринта, с рекомендованной длительностью не более 3-х часов, для месячных спринтов», — именно такие подсказки дает Скрам-гайд.

Действительно, это время, обычно в конце спринта, которое есть у команд, чтоб проанализировать себя.

Практикой подтверждается, что если длительность спринта подобрана оптимально, то у команд есть время успеть попробовать новые подходы и приемы, и убедиться, что для них работает лучше, что хуже, на что следует обратить внимание. Возможно, уже возникает вопрос, зачем же ждать Ретроспективы, если можно пробовать что-то новое «на лету»? Ответ прост: конечно, можно, но в том числе Ретроспектива спринта — отличная формальная возможность для реализации этого.

Часто фигурирует формулировка: «Что случилось на Ретро, остается на Ретро». Для того, чтобы данное событие происходило максимально эффективным, команды должны чувствовать себя защищенными и не бояться высказаться по «болезненным» для них темам. На Ретроспективу ходит только Скрам-команда, поэтому априори на дверь комнаты, где она будет происходить, можно смело вешать табличку «Посторонним вход воспрещен», а посторонними являются все, кроме команды разработки, владельца продукта и скрам-мастера.

Какими были Ретроспективы в до КОВИДную эпоху, и как они изменились в постКОВИДную

Иногда слышится в менеджерских курилках, «вот были времена, когда на Ретроспективы люди физически ходили». Но такое выражение было валидным только для команд, которые работали в одном здании, этаже, офисе... Действительно, COVID-19 внес определенные коррективы в работу команд разработки, но сугубо виртуальное общение было нормой для распределенных команд в «до COVID-ную» эпоху.

Сейчас же большинство Ретроспектив проходит в гибридном режиме, когда часть команды физически находится в одном помещении, а другая часть (отдельные члены команды или также группы) подключаются виртуально. Фасилитировать виртуальные ивенты сложнее, чем полностью офлайные. Кто-то параллельно присматривает за ребенком или встречает курьера с едой, кто-то лихорадочно допиливает код...

Но наибольшая сложность, с которыми сталкивается скрам-мастер при онлайн Ретроспективах — это выключенные камеры. Это фактически делает невозможным понять, находится ли «с тобой» коллега или нет. В случае же, когда команда находится перед глазами скрам-мастера — можно сразу определить, кто выпал из ивента, отвлекся на что-то и легче вовлечь его обратно. Но, будем откровенными, если скрам-мастер приходит неподготовленным, то удержать команду вовлеченной становится еще сложнее. Ретроспективы без подготовленной адженды — часто впустую потраченное время.

В качестве приготовлений, скрам-мастер может подготовить активность для привлечения внимания команды, может быть какая-то короткая игра, продумать план ретроспективы и разбить все время Ретроспективы на временные слоты, которым он будет помогать придерживаться команде. На самой ретроспективе не обязательно акцентироваться на улучшениях, они могут быть очевидны и в таком случае не имеет смысла тратить на них лишнее время. Лучше заранее подумать, как можно подтолкнуть команду к экспериментам: плохо с качеством, давайте сделаем процедуру приемки от дева к тестеру, например. В следующий раз проверяем результат эксперимента и решаем: пролжаем эксперимент, результат достигнут, проблема уже не проблема.

«Хорошая» или «плохая» Ретроспектива. На что обратить внимание скрам-мастеру и девелоперам

Достаточно сложно разделить на «белое и черное» все Ретроспективы. Но скорее всего, если все инпуты к Ретроспективе сводятся к следующим цитатам: «Все хорошо», «Вылились удачно в прод», «Мало зарепортили багов», с большой долей вероятности, вы ее делаете неправильно. Хотя и такие инпуты могут и должны иметь место быть.

Скорее проблема, когда команда посылает такие месседжи от Ретроспективы к Ретроспективе. Три классических вопроса «Что было хорошо», «Что было плохо», «Что мы хотим улучшить», как и подсказка на дейлик «Что я делал, что буду делать, мои блокеры и чем помочь коллеге» уже изжили себя.

Проведение Ретроспектив по шаблонам часто не эффективно, и в какой-то момент команда может начать приходить на ивент, только чтобы посидеть и отдохнуть, а если повезет — и поесть пиццы.

На протяжении всего спринта команда проходит целый путь: планирование работы, ее выполнение и завершение. Одной из задач скрам-мастера является наблюдать за командой на этой дистанции и выделять для себя, т. к. команда сама может не видеть «узкие» места и выносить их на обсуждение.

Подсказывать им, «ребята, вот была ситуация, в которой...» или «не кажется ли вам, что вот этот процесс не эффективен» и т. д. Тут подошел бы совет: покажите на собственном примере, как можно генерировать темы для Ретроспектив. Достаточно мачурные команды могут это делать и сами, но иногда даже в них нет желания «закатывать рукава» и погружаться в тяжелые темы.

В принципе Ретроспектива без адженды также возможна, для таких случаев может подойти формат «lean coffee», во время которого команды прямо на ивенете накидывают темы и разбирает их после приоритезации, или же refinement беклога с enhancements команды от предыдущих Ретроспектив. Такой должен обязательно быть у команд и рекомендация — просматривать его время от времени и подчищать. Неделание этого скорее разочарует команду и выльется во вполне валидные комментарии: «Так мы же это говорили уже, все равно ничего не меняется»...

Ретроспектива — митинг не для скрам-мастера, а для команды

Ложное мнение, что во фреймворке Scrum первую роль играет скрам-мастер. Весь фреймворк заточен под команду и основной посыл Ретроспективы — принести пользу команде через внедрение каких-либо изменений, которые команда попытается внедрить в следующем спринте.

Я часто задаю вопрос кандидатам на интервью: «Какой из скрам-ивентов ваша команда прекратит делать первым, если, к примеру, завтра она останется без скрам-мастера?» и в 99% случаев ответ звучит именно «Ретроспектива».

Почему же? Есть два ответа:

  1. В таких командах Ретроспектива проводилась неправильно и сама команда не видит ценности в ивенте.
  2. Достаточно сложно копаться в себе и если можно избежать поднятия острых, релевантных тем, поверьте, команды захотят избавиться от таких событий.

Трансформация Ретроспективы: из «coffee talks» в «action oriented»

Если на Ретроспективу нет подготовленной агенды, она может превратиться в бесструктурный, базарный ивент, и его ценность в понимании команд сразу же уменьшиться. Повторюсь, Ретроспектива нужна командам для того, чтобы посмотреть на себя с другой стороны, выявить пробелы и с помощью внедренных изменений попытаться их исправить, затем через некий период посмотреть, проанализировать и понять, что сработало, что нет.

Вполне реальны случаи, когда внедрение запланированных изменений с треском проваливались. Это нормально. Это еще один выученный урок. Нужно не бояться, что-то пробовать, менять подходы.

Распространена примерно следующая фраза: «С нами работают, чтобы мы писали код, а не предлагали изменения». Команда может почувствовать себя эдакими революционерами, которым все не так, и которые вечно пытаются что-то изменить. Конечно, изменения ради изменений не должны быть, но продакт-менеджеры и продакт-лиды чаще адекватно воспринимают желания команд что-то поменять. Больше того, если в компании, с которой вы работаете, Agile-трансформация проходила более-менее здоровым образом, а не просто в один день решили следовать Agile и Scrum, то стейкхолдеры прекрасно понимают ценность скрам-ивентов и могут иногда даже активно предлагать помощь и инициировать улучшения.

Также, в зависимости от мачурности команды, Ретроспектива может проходить по-разному. У только что образовавшихся команд Ретроспективы, скорее всего, будут адресованы на изменение рабочего процесса на более эффективный с точки зрения команды. У более мачурных команд, которые просуществовали уже год и более, может быть «кризис Ретроспектив». Тому может быть несколько причин:

  1. Команда уже успела вложить большое количество усилий в улучшения и уже работает как отлаженный «швейцарский механизм». В таких случаях сама команда может приходить к скрам-мастеру и предлагать увеличивать интервалы между Ретроспективами. Скорее, это здоровый признак, но также стоит задуматься, может и длину спринта следует пересмотреть, а может команда просто закрывает глаза на какие-то вещи и не хочет с ними справляться.
  2. Команда смогла достичь минимума «покращень» и не видит целесообразности в еще одной встрече, чтобы переливать из пустого в порожнее. В таких случаях у скрам-команды большие проблемы и нужно что-то делать. Как правило, у таких команд почти бесконечный бэклог enchancment-ов и скорее всего, Ретроспективы они делали, потому что так написано в скрам-гайде. Но даже из такой ситуации можно найти выход.

Практические примеры и советы

Если ваш бэклог улучшений стремится к бесконечности, и вы с командой его не пересматривали уже пару месяцев — задумайтесь, может стоит его просто удалить? Хорошим следующим шагом может быть Ретроспектива в формате «Sailboat». Но после такого перезапуска не забывайте просматривать бэклог улучшений и работать с ним.

Если надежды на Ретроспективу нет, не будем вдаваться по каким причинам, скрам-мастер может всегда предложить минимум два варианта:

  1. Пройтись с командой по бэклогу улучшений и удалить то, что более не релевантно и приоритизировать то, что все еще важно для команды — можно провести голосование по элементам этого бэклога и, к примеру, отрефайнить эти элементы, как и обычные таски из продакт-беклога.
  2. Если и бэклог улучшений пуст, Lean coffee — отличный формат.

Если вы начали Ретроспективу и чувствуете, что команды «нет на месте», нужно иметь несколько инструментов айс-брейкеров, которые помогут разговорить команду. Для онлайновых ивентов можно попросить каждого показать, какой у него/нее вид из окна, или кто во что обут, можно также приготовить какой-нибудь квиз, например, в Kahoot.

Для офлайновых ивентов можно предложить сыграть в игру, например «Крокодил», достаточно всего несколько раундов. Или же моя любимая — I’m going to the beach and...

Успешных вам скарм-ивентов, и пусть ваши Ретроспективы работают на перспективу!

Понравилась статья? Нажимай «Нравится» внизу. Это поможет автору выиграть подарок в программе #ПишуНаDOU

👍НравитсяПонравилось7
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Зачастую в подобных темах в комментах безнадега и жесткая критика. От же скрам паршивый, не дает разрабатывать...
Ретроспектива только тогда ретро если после нее есть изменения. Эти изменения должны быть маленькими, конкретными, приносящими очевидную пользу и выполнимыми. Что где и когда менять решает сама команда.
По опыту могу сказать что самое тяжелое в ретро это приводить в жизнь изменения. Зачастую подход — «работает — не трожь». Потому почти все идёт со скрипом.
Если нет должного уровня организации и поддержки команды в изменениях, то так и будут в темах о ретро ныть про скрам и что вообще лучше писать лишь код, а не тратить время на действительно проявления карго культа.

Во всех компаниях где я работал ретроспектива всегда была таким себе выпусканием пара, без каких-либо изменений после нее. Так что пользы от нее ноль

Объясните мне для чего применять скрам?

Внизу уже писали

Простите, а какой Agile или даже Scrum может быть в аутсорсе? 99.9% проектов работают по Fixed Price или много реже по Time & Material схеме.

Для новых проектов скрам вообще не подходит. Заказчик хочет знать сколько ему это будет стоить. Для легаси сапорт проектов в cкраме тоже смыла нет. Накидали багов в канбан доску и вперед фиксить, двигать кнопки на пару пикселей и т.д.

Где применять скрам? Как вообще в скраме может строиться нормальная архитектура? Agile такой agile. Докидаем задач в продукт беклог по ходу проекта, а сейчас пилите что есть. В итоге архитектура получается через сраку...

Очередной аджали булшит. Как переливать из пустого в порожнее что бы тебя не уволили с работы. Если есть проблема/предложение то зачем ждать 1-4 недели до ретро? Я попытаюсь решить/озвучу это сейчас и забуду, а не буду носить это в своей голове несколько недель.

Если есть проблема/предложение то зачем ждать 1-4 недели до ретро?

Ну как же зачем? Есть фреймворк и его церемонии. Scrum ведь agile? Вот и развивайте гибкость памяти чтобы не забыть это озвучить через 2 недели на ретро :)

Очередной аджали булшит. Как переливать из пустого в порожнее что бы тебя не уволили с работы

Так в этом и суть этих весьма интерсных социальных игрищ — гибко подстраивать себя под все правила и обряды и делать хорошую мину при плохой игре

Scrum/SAFe — имеющие ничего общего с Agile, созданные для чисто комерческих целей и зарабатывания на всем движении гибких методологий. Или компания считает свои команды разработчиков такими тупыми что они не могут освоить 10 страниц гайда и им нужны скрам мастера для этого?
А полюбился и прижился скрам еще за то, что там есть estimation-ы, которые не работают, но на которые так уповают еще одни дармоеды, ценители хлыста и пряника.

В этом плане, куда более симпатичен Kanban, который осваивается за пол часа, не требует гайдов, курсов и сертификаций для канбан-мастеров и строится таки на базе основных принципов Agile.

чтобы бэклог не стремился к бесконечности

Не писать бесконечное количество follow-up story, и если 3 стори поинта хорошо бы превратить в 10-13 и избехать технического долга — раздувать естимейт и делать все появившиеся follow up в рамках спринта.

Дякую, але не вистачає прикладів із вашого власного досвіду.
Наприклад, як ми правильно чи неправильно проводили ретро.
Зі свого досвіду скажу, що онлайн-ретро проводяться на ура, для мене в них головний плюс — можливість розібратися з тими проблемами, які псують життя і на які не вистачає час протягом спринту.

Простите, а какой Agile или даже Scrum может быть в аутсорсе? 99.9% проектов работают по Fixed Price или много реже по Time & Material схеме. Если заказчик в аустсорсинге не готов платить в том числе и за эксперимент, и за изменения (переработку функционала), к тому же требует зафиксировать содержание, бюджет, сроки, о каком Agile, Scrum и ректоспективе может идти речь?

Назовите хоть одну причину почему девелоперы на любой галере должны быть заинтересованы в ретро, если завтра их может заменить другой гребец из какого-нибудь Бангалора, а у самой галеры вообще другая схема профита и нулевая заинтересованность в успехе развития бизнеса заказчика и его долгосрочных стратегических перспектив?

Ретроспектива как и постоянная и частая обратная связь с заказчиком — ключевой момент здорового Agile-а. Формальные методологии, церемонии и процессы здесь не имеют никакого значения.

Ви цитуєте версію Скрам Гайду від 2017:

«Ретроспектива Спринта — это возможность для Скрам‐команд исследовать себя и создать план улучшений для следующего Спринта, с рекомендованной длительностью не более 3-х часов, для месячных спринтов»,

А от у версії від 2020 року підхід був дещо зміненим. Основне — це те, що прибрали акцент на необхідності вносити покращення з ретроспективи одразу ж у беклог наступного спринта.

кроме команды разработки, владельца продукта и скрам-мастера

У версії Скрам Гайду від 2020 року поняття development team теж зникло.

Ретроспектива — митинг не для скрам-мастера, а для команды

У Скрамі немає зустрічей/мітингів, є події. Не скрізь у статті це коректно відображено.

Если ваш бэклог улучшений

Скрам передбачає наявність лише двох беклогів: продукту і спринта. І покращення процесу мали б опинитись в одному з них. Інакше Ви шкодите принципу прозорості.

Убеждена, что ретроспектива — самая важная встреча в скрам. И какого бы уровня зрелости и слаженности не достигла команда, ценность ее не снижается. Однако формат можно и нужно менять в зависимости от того, где сейчас команда.

Ретроспективы не умрут, если:
1) в команде есть доверие и открытость, поощряется любая обратная связь в корректной форме, команда умеет благодарить друг друга, а не только критиковать
2) формат проведения ретро меняется, и фасилитатор не настаивает на своем плане проведения встречи, а подстраивается под диалог команды, имея в запасе несколько вариантов активностей на разные ситуации
3) на ретро команды договариваются о следующих шагах не ради менеджмента, а ради создания лучшей версии команды и процессов, и эти действия остаются не на доске/стикерах/МоМ, а включаются в беклог и осуществляются

Высший пилотаж скрам мастера — научить команду проводить ретро самостоятельно, например во время его отпуска :) И это возможно, когда команда чувствует ценность этой встречи и понимает ее цели.

Напоследок маленькая, но полезная практика.
Пускай ссылка на доску для ретро будет постоянно доступна, и следующие ретро проводятся рядом с предыдущими — так легче отслеживать динамику договоренностей.
Создайте отдельную зону — «парковку», на которую в течении спринта команда может добавлять идеи для будущего ретро, темы для обсуждения, свои наблюдения. Это помогает «вынуть из головы» ценные мысли, когда до ретро ещё долго, и легко вернуться к ним во время ретро.

Всем осознанных и полезных ретроспектив :)

И что характерно, никто кроме срам-мастеров так не считает.

Высший пилотаж скрам мастера — научить команду проводить ретро самостоятельно, например во время его отпуска :)

я думал научить команду делать скрум самостоятельно и вообще делать скрум это не то что бы «высшее предназначение» но тупо просто работа скрум мастера просто сама по себе

читай если команда «делает скрум» на постоянном контроле читай из-под палки то к.м.к. если сомнения это ли действительно скрум или уже «это другое» (к) (тм)

Создайте отдельную зону — «парковку», на которую в течении спринта команда может добавлять идеи для будущего ретро, темы для обсуждения, свои наблюдения. Это помогает «вынуть из головы» ценные мысли, когда до ретро ещё долго, и легко вернуться к ним во время ретро.

обычная длина спринта 2 недели если за 2 недели это «когда до ретро ещё долго» то прямо значит текущая операционная рутина заедает на столько что первым вопросом на ближайшем же ж «ретро» надо прямо ставить «чо за на нам не до этих ваших ретро тут работать надо» и решать сперва его а потом уже всё остальное «идеи добавленные в течение спринта вынутые из головы ценные»

команда либо знает зачем её «ретро» вообще либо нет и это такая же ж «манки рутина» как и всё остальное копроративный буллшит

Чому в тексті слово «ретроспектива» пишеться з великої літери?

«Потому что ты говоришь о Скраме, но делаешь это без уважения» ©

Отвлечённый вопрос про

Достаточно мачурные команды

«Достаточно адалтные команды» не саундится ли беттернее?

Звучит красиво, а ситуация страшная. Всё, что могут сделать такие «ретроспективы» — это одновременно заставить смириться с тем, что ничего не поменяется ни в раскладе, ни в процессе — но результаты должны быть иными, хотя ни одна проблема решаться не будет, а кто её ещё раз поднимет, да и любую другую — тот душнила и стукач.

Другими словами, это один из элементов бюрократизма: установить ритуал, не имеющий полезности, с тем, чтобы подавить противоречия ради защиты самого ритуала, а также выявить и подавить тех, кто с противоречиями не согласен, и назвать именно их проблемой. Чем более раздуто руководство, тем тяжелее и опаснее эти ивенты, сводящиеся по сути к поиску путей инсталляции бюрократического рака.

А что на самом деле: для обратной связи критическим ресурсом является время. Чем быстрее она происходит, тем меньшего воздействия требует, и тем ниже риски, что она окажется чрезмерной. А эти риски в обратной связи не устранимы, поскольку как правило обратная связь не нормируема по воздействию — иначе это потребовало бы высокоинтеллектуального образованного руководства, с хорошей оплатой, зависящей от результатов процентов на 80. Если так сорить деньгами не принято, приходится инсталлировать навыки руководства во все звенья, делая его распределённым. Но это требует ещё большей образованности, ибо корректировать придётся уже третью производную — а она силой не корректируется, только дипломатией.

Отлично расписано, аплодирую стоя

Подписаться на комментарии