Привет! Меня зовут Лёша Дидух, я тимлид команды личного кабинета в Skyeng. Это текстовая адаптация моего доклада про ретроспективы на DUMP-2022 в Екатеринбурге.

Когда я пришёл в компанию пару лет назад, то немножко обалдел от разницы в подходах к управлению проектами и командами между моей прежней работой и Skyeng. Такой скачок между диаметрально противоположными культурами заставил меня переосмыслить и собрать воедино всё, что я знаю о ретроспективах. Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?».

В конце статьи можно найти запись доклада по теме.

Начнем издалека (но не просто так)

В 2000 году влиятельные ребята из мира IT, среди которых были Роберт Мартин (автор принципов SOLID и огромного числа книг про программирование) и Джеф Сазерленд (один из авторов Scrum), встретились, чтобы, как говорит сам дядя Боб, лучше узнать друг друга в надежде, что тесное общение приведет к чему-то интересному.

Каждый из присутствующих был или автором легковесных методик вроде XP или Crystal Methods, или признанным экспертом в разработке ПО. И несмотря на совершенно разные инструменты, выяснилось, что в основе этих подходов лежат общие идеи. Квинтэссенцией этих идей стал Agile Manifesto.

С тех пор прошло больше 20 лет. Сейчас может казаться, что это артефакт древних старцев на берестяных грамотах с пространными рассуждениями о бытие. На самом деле это превосходный пример индукции, ведь манифест — это обобщение свойств рабочих подходов, которые успешно себя показали в реальной работе.

И двенадцатый принцип этого манифеста гласит:

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

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

Мы можем рассмотреть продукт или команду как некую систему. В текущем состоянии системы нам интересны проблемы.

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

В будущем состоянии системы было бы здорово ощутить эффект от внедрения изменений. Это может быть, например, уменьшение времени на найм senior разработчика в команду. Мы не можем сократить это время просто так, закрыв глаза и загадав желание. Поэтому приходится реализовывать какие-то инициативы в надежде, что они приведут к желаемому эффекту. Вся сложность в том, что системы инертны, и эффект от изменений происходит через какое-то время, да и вовсе может быть не таким, каким хотелось бы.

Получается, что ретроспектива должна ответить на три вопроса:

Что мы хотим изменить?
На что мы хотим изменить?
Что нужно сделать, чтобы привести систему из одного состояния в другое?

Дальше мы пойдём по классическому сценарию ретроспективы и рассмотрим, что нам может помочь в этом нелёгком деле. Я буду приводить примеры разных механик и концепций, чтобы объяснить суть, но есть масса альтернатив, которые вы можете придумать сами или найти на ресурсах вроде https://www.funretrospectives.com/funretro/.

1. Фаза check-in (разогрев, открытие)

Психолог Даниэль Канеман в книге «Думай медленно, решай быстро» ввёл понятия быстрого и медленного мышления. Быстрое мышление работает мгновенно и не требует ментальных усилий — идеально подходит для решения простых задач. Медленное мышление энергозатратнее, но способно решать более сложные задачи.

Эту мысль иллюстрирует эффект Мюллера-Лайера:

На рисунке изображены отрезки одинаковой длины. Мозг вроде как это понимает, но всё равно ему требуется прикладывать усилие, чтобы это увидеть. И виной всему именно несовершенство быстрого интеллекта.

А мы собрались не просто чаи гонять, поэтому ретроспективы начинаются с фазы check-in, чтобы команда вышла из режима «пишем код» и настроилась на рефлексию. Как это сделать?

Вариант 1 — Анализ результатов прошлой ретроспективы

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

Вариант 2 — Игровые механики

Кто-то скажет, что это на уровне утренника в детском саду, но для каких-то команд работает. Опиши одним словом прошлый спринт, emoji art или, например, ESVP. Название — аббревиатура 4 ролей: Explorer, Shopper, Vacationer, Prisoner. Мы просим каждого участника ретроспективы отнести себя к одной из категорий людей.

Исследователь. Пришел на ретро, потому что радеет за команду и ощущает себя не иначе как мистером Вульфом (который решает проблемы).
Покупатель. Деловой человек пришёл, чтобы решить свои проблемы, а остальное его не сильно волнует.
Отпускник. Наверняка не включил камеру и, скорее всего, уже открыл бутылку пива. Ему в целом не очень тут интересно, но хоть какой-то повод отвлечься от работы.
Заключенный. Просто хочет писать юнит-тесты, а тут ты со своим ретро. Парадоксально, но мне кажется, что эти ребята подсвечивают самые острые проблемы.

Для тимлида/скрам-мастера это лишний повод что-то узнать о людях и их настроении, а для команды возможность расслабиться и через шутки-прибаутки настроиться на рабочий лад.

Вариант 3 — Squad Health Check

Это опрос из десятка пунктов, который придумали в Spotify. Лично я для своей команды взял только идею и составил свой вариант. Эта техника позволяет численно измерить показатели здоровья команды.

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

2. Фаза инспекции

Команда заряжена искать ответ на вопрос «Что мы хотим изменить?».

Вариант 1 — Went well, went wrong

Стандартный формат — просим команду записать мысли на виртуальной доске, разделенной на 2 зоны: «Это было хорошо» и «Это было плохо».

Советую easyretro.io, здесь легко заводить карточки и управлять ими. Подобную доску нужно держать держать в быстром доступе команды и приучить всех записывать мысли сразу, как только они появились, чтобы не позабыть за спринт, что там у нас было.

Вариант 2 — Тематические механики

На этапе сбора проблем тоже есть место для фана, например зомби-ретро. Рабочую область в Миро делим на три зоны. В первой подчеркиваем сильные стороны команды.

Во второй — собираем проблемы, с которыми сталкивается команда.

В третьей части мы пытаемся укрепить периметр, используя сильные стороны команды.

Вместе все складывается в такую забавную картину:

Формат классный, ненавязчивый. Помогает командам, застрявшим в унылых ретро.

Вариант 3 — Ограничение контекста

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

FLAT — это ещё один пример подобного подхода.

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

Почему стоит экспериментировать с форматами?

В 1967 году Швеция переходила с левостороннего движения на правостороннее. В первые месяцы перехода количество ДТП уменьшилось. Вместо того, чтобы рулить на автомате, приходилось напрягаться и включать медленное мышление. Так и ретроспективы — новые сценарии не дают команде идти по накатанной.

3. Фаза приоритезации

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

Выравниваем контекст

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

Плохо: Почему QA не может заниматься задачами из спринта, когда у него упала рабочая среда?

Хорошо: Что делают QA, когда в середине дня падает рабочая среда и команды инфраструктуры говорит, что до конца дня она не поднимется?

Паркуем лишнее

Парковать — значит откладывать обсуждение на потом. Что-то более-менее однозначное можно обсудить в рабочем чате асинхронно. А если на ретроспективе нет нужных людей или не хватает каких-то данных, то можно оставить карточку до следующего ретро или запланировать отдельную встречу.

Выбираем, над чем будем работать дальше

Здесь есть два варианта — демократический и не очень.

В Miro или том же easyretro.io можно запустить голосование, чтобы команда сама выбрала, что для неё важно. Но людям свойственно иногда избегать острых тем, поэтому как тимлид я всегда оставляю за собой право сказать: «Я хочу, чтобы мы сфокусировались вот на этом».

4. Принятие решений

Симптомы выявлены, но мы не терафлю — нам нужно убить не симптомы, а проблему. Для поиска первопричин есть много известных способов, вроде:

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

Диаграмма «грозовая туча»

Это диаграмма помогает бороться с конфликтами через поиск наименьшей общей ценности. Например, разработчик считает, что он имеет право общаться со стейкхолдерами и вносить после этого изменения в задачи. Продакт хочет, чтобы все изменения шли только через него.

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

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

Деревья текущей реальности, будущей реальности и изменений.

Несколько лет назад я сформулировал для себя главную проблему метода «пять почему» — он не поддерживает ветвления. Если мы посмотрим на классические примеры, то увидим что-то вроде:

[Вопрос]: Почему не выпустили релиз вовремя?
[Ответ]: Потому что не правильно оценили задачу.

[Вопрос]: Почему не правильно оценили задачу?
[Ответ]: Потому что плохо её декомпозировали.

[Вопрос]: Почему её плохо декомпозировали?
[Ответ]: Потому что аналитик работал над требованиями к другой задаче.

Но в жизни всё не так однозначно. Релиз выпустили с опозданием еще и потому, что заболел lead developer, который в этот модуль никого, кроме себя не пускает. А еще бизнес поменял требования к задаче, но почему-то не сдвинул сроки. Таких причин может быть много, и это не укладывается в стройный принцип «один вопрос — один ответ». Поэтому для своей команды я немного изменил механику «пять почему»:

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

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

Дерево текущей реальности

Дерево текущей реальности начинается со сбора нежелательных явлений, которые стоит формулировать аккуратно — так, чтобы они были объективны, не содержали оценочных суждений и не являлись предполагаемой причиной.

Исходные предпосылки Дерева Текущей Реальности

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

Дерево текущей реальности, достроенное до корневой проблемы

Дерево будущей реальности

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

Дерево переходов

Идеи это еще не решения. На пути к совершенству возникает много нюансов, и прежде, чем нырять с головой в реализацию, стоит задуматься — хватит ли сил дойти до конца? Планирование изменений начинается с построения дерева переходов. На этом этапе нужно составить план действий, оценить риски и способы борьбы с ними, сформировать критерии понимания, что всё идёт в правильном направлении.

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

5. Check Out

Мы ответили на вопросы:

Что хотим изменить;
На что хотим изменить;
Что нужно сделать, чтобы привести систему из одного состояния в другое.

Осталось сформировать задачи, подходящие под SMART-критерии (кстати, некоторые команды добавляют такие задачи в Jira и работают с ними как с обычными задачами, и это довольно круто), поблагодарить команду и можно расходится.

Не кажется, что я что-то упустил?

Это всё не работает

Поговорка «Гладко было на бумаге, да забыли про овраги» как раз про это. Люди не вовлечены, фокус на интеллектуальных баталиях, обсуждаются слишком мелкие проблемы или, наоборот, проблемы вселенной и всего такого. Как итог — решения не принимаются, команда топчется на одном мест, доверие к ретроспективе падает.

Здесь самое время остановиться и вспомнить, что цель ретроспективы — не сама встреча, а эволюция команды. И с одной стороны, мне нравится идея вовлекать команду в этот процесс. Сообща проще бороться со сложностью и изменчивостью этого мира. К тому же, именно в спорах рождается истина. Да и пресловутый синдром Not Invented Here никто не отменял.

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

Драйвером изменений может выступать scrum master, но я вижу проблему в том, что они обычно не берут на себя активную роль. Они могут фасилитировать встречи, проводить воркшопы, но вот взять и с нуля разобраться в проблеме, предложить решение и внедрить его — такого я ещё не встречал (если у вас другой опыт и вы готовы с этим поспорить, буду рад прочитать ваши истории в комментариях).

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

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

Так что всё-таки делать, если ретро не работает?

Тюнинг ретроспективы

Я бы выделил несколько факторов успеха ретро:

Дизайн команды. Не стоит требовать от людей то, что они не готовы дать, поэтому нужно знать интересы и опыт каждого члена команды.
Понимание границ ответственности. Важно определить, что команде не подвластно, на что она может косвенно влиять, и что находится полностью в её зоне ответственности.
Климат команды. Без доверия и рабочей атмосферы ретроспектива будет состоять из дежурных фраз. Людям свойственно замалчивать острые проблемы, а зачастую именно они оказывают самое серьезное влияние на работу. Очень классно про это рассказано в книге пять пороков команды в главе про доверие.

Всё это стоит как минимум проанализировать, а как максимум обсудить с командой, и уже после этого вносить коррективы.

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

Ну и помните, что ретроспектива не единственный способ двигаться вперёд. Не пренебрегайте встречами 1:1, но и сделайте их более неформальными. Не стоит давить из себя слова, когда сказать нечего.

И я бы хотел рассказать про задачу-рефлексию. Это своего рода ретроспектива, которая делается автономно, эдакая домашняя работа. Я составляю опрос в гугл-форме (вот пример одной из таких задач) и прошу команду его пройти. Плюс такого подхода в том, что человек делает это без внешних раздражителей в удобное время в комфортном для себя темпе и без лишнего эмоционального давления со стороны коллег. В таком формате могут всплывать мысли, которые не каждый осмелится высказать голосом на встрече на 10 человек.

Заключение

Что я хотел всем этим сказать. Относитесь к ретроспективам более внимательно. Этот инструмент кажется понятным, но его обманчивая простота часто приводит к застоям и стагнации. Следите за здоровьем этого процесса, всегда задумывайтесь, почему вы делаете то, что делаете. Помните, что ретроспектива не цель, а средство. Не смотрите на неё, как на единственный способ реагировать на дисфункции команды. Инвестируйте своё время в рост культуры общей ответственности у команды, но и не занимайте позицию Actively Doing Nothing. Включайте своё медленное мышление и не бойтесь ломать то, что плохо работает.

Всем мир!

А вот и видео-формат доклада.

Ретроспектива. Doin’ It Right