Про ретроспективу, прилагательные и бетонный отбойник
Ретроспектива — одно из пяти событий Scrum. Про то, как проводить ретроспективы написано множество статей и книг. Дизайны ретроспектив предлагают специальные интернет-порталы и печатные колоды карт.
Но при всём этом разнообразии материалов, ретроспективами команды часто пренебрегают. На мой взгляд, причиной этому является отсутствие окупаемости затраченного на встречу времени. А проводить встречи с низким или нулевым КПД - весьма дорого.
Я предлагаю 3 несложных совета, не зависящих от дизайна встречи, которые помогут вам повысить её качество.
Дисклеймер: все советы и приведённые примеры транслируют исключительно мой субъективный опыт. Данные рекомендации не отменяют необходимости подготовки, фасилитации и прочих обязательных для успешной встречи вещей.
Итак.
#1. Доводите встречу до конца
Да, самый первый совет является и самым банальным. Но его не было бы в этом списке, если бы об это так часто не спотыкались начинающие команды.
Ретроспектива - непростая встреча, предполагающая прохождение нескольких этапов, в результате чего у команды появляется план улучшений.
И порой бывает так, что время, отведённое на встречу, заканчивается быстрее, чем команда доходит до составления плана. И тогда разворачивается один из сценариев:
- Кто-то из команды уходит на другую (следующую) встречу и оставшиеся продолжают ретроспективу;
- Команда договаривается продолжить (с того же места) на следующей ретроспективе;
- Команда договаривается поставить дополнительную встречу в ближайшее время, чтобы продолжить там.
Нельзя сказать, что какой-то из вариантов грозит миру волной катаклизмов, но брошенная на середине встреча без достижения намеченного результата обычно означает зря потраченное время.
Потому что к следующей ретроспективе появятся новые темы/проблемы, обсуждение которых полностью обесценит прошлую встречу.
Продолжение ретроспективы без кого-то из команды также не идет на пользу: дальнейшие обсуждения могут продолжиться без инициатора поднятой темы (или без учета его/их мнений), либо принятые решения могут стать не легитимными, так как голосование проходило не полным составом.
Поэтому, чтобы запороть встречу еще до её начала - запланируйте на неё всего час (а лучше - полчаса) времени, и следом поставьте в календарь без перерыва следующие встречи.
Встреча, не закончившаяся составлением плана - плохая встреча.
Важно научиться проходить все этапы ретроспективы, а уже вторым шагом - научиться эти этапы сжимать до разумного минимума.
#2. SMARTуйте договоренности
Вы наверняка знакомы с понятием S.M.A.R.T.-цели. И хорошо, когда результатом встречи является так называемый «отSMARTованный план» (т.е. план, в котором каждый пункт является конкретным, измеримым, достижимым, актуальным и ограниченным по времени).
Однако, сложность в том, что неподготовленная команда даже при хорошем дизайне встречи и качественной фасилитации может создавать договоренности вроде «лучше читать аналитику».
Всё потому, что ретроспективы мало уметь проводить. В них нужно уметь участвовать.
Чтобы ретроспектива не переросла в митап по SMART, можно задать некоторые рамки, в которых команда продолжит генерацию идей:
Не используйте слова «больше», «меньше», «лучше», «чаще» и т.д. не указав единицу измерения.
Фраза «лучше тестировать» не имеет смысла, т.к. её невозможно выполнить, т.к. невозможно сравнить с предыдущим результатом
Если предыдущего совета окажется мало, можете пойти дальше - и вовсе не использовать прилагательные и наречия. Выражения, наполненные этими словами часто могут трактоваться по-разному, т.е. быть причиной разночтений.
Попробуйте сами - исключаем из фраз слова без конкретики (вызывающие разночтения) - и фразы начинают терять смысл:
«При следующем звонке [вежливей] разговаривать с клиентом».
«[Качественней] проводить этап тестирования»
- Не договаривайтесь о том, что должно происходить «в голове». Договоренности вроде «быть внимательней на совещаниях» и «спокойнее относиться к срочным задачам» также невозможно выполнить, т.к. невозможно однозначно определить их соблюдение;
- Попробуйте практику назначения «SMART-офицера» - выбрать на встрече любого члена команды, задачей которого было бы ставить под сомнение выполнение любой из принятых договоренностей, исходя из их текущих формулировок. SMART-офицер следит за тем, чтобы у каждого пункта созданного плана был исполнитель, установлены сроки, а главное - формулировка не содержит потенциальных разночтений и пр.
Качественно составленный план - это уже половина дела. А для закрепления успеха вам может понадобиться еще кое-что.
#3. Делайте договоренности явными
Однажды, чтобы разделить автомобильные потоки, люди договорились нанести на дорогу сплошную линию, и условились ее не пересекать. Однако, само правило лишь условно защищено от нарушений через возможный штраф для тех, кого заметит инспектор или автоматическая камера. В тех местах, где пересечение является особо критичным - не рисуют сплошных линий. Там ставят бетонный отбойник, который физически нельзя пересечь.
Этот же принцип следует соблюдать и для генерации договоренностей на ретроспективе: чем критичнее нарушение принятого правила, тем важнее договориться о реализации невозможности его нарушения.
Еще будучи разработчиком я обратил внимание, что договоренность «обязательно добавлять комментарии к SQL-коду, сохраняемому в таблицу N» легко нарушалась (по разным причинам) до тех пор, пока не была перефразирована в «добавить в таблицу автоматическую проверку на наличие в сохраняемом коде символов комментирования (т.е. //)». Да, и эту договоренность можно было обойти, но сделать это случайно уже было невозможно.
У договоренности, которая становится явным правилом - сильно выше шансы быть выполненной.
Также, «побочным эффектом» такого подхода будет снижение порога вхождения в вашу команду. Новичкам нужно будет меньше объяснять ваши принципы работы - сама система не будет позволять обходить важные договоренности.
Резюме
Ретроспектива не умеет приносить пользу минуя план улучшений. А значит, чтобы встреча оказалась полезной для команды - нужно, во-первых, этот самый план на встрече создать, а, во-вторых, сделать план таким, чтобы у команды не возникало излишних сложностей при его выполнении и валидации.
Договоренности, содержащие потенциальные разночтения; эмоциональные, а не технические детали - будут для команды в разной степени бесполезны, а с учётом затраченного времени на их создание - еще и весьма дорогим отвлечением команды от её основной работы.
И главное: не ретроспектива решает проблемы. Проблемы решают люди.