Про ретроспективу, прилагательные и бетонный отбойник

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

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

Я предлагаю 3 несложных совета, не зависящих от дизайна встречи, которые помогут вам повысить её качество.

Итак.

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

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

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

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

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

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

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

Важно научиться проходить все этапы ретроспективы, а уже вторым шагом - научиться эти этапы сжимать до разумного минимума.

Вы наверняка знакомы с понятием S.M.A.R.T.-цели. И хорошо, когда результатом встречи является так называемый «отSMARTованный план» (т.е. план, в котором каждый пункт является конкретным, измеримым, достижимым, актуальным и ограниченным по времени).

Однако, сложность в том, что неподготовленная команда даже при хорошем дизайне встречи и качественной фасилитации может создавать договоренности вроде «лучше читать аналитику».

Всё потому, что ретроспективы мало уметь проводить. В них нужно уметь участвовать.

Чтобы ретроспектива не переросла в митап по SMART, можно задать некоторые рамки, в которых команда продолжит генерацию идей:

• Не используйте слова «больше», «меньше», «лучше», «чаще» и т.д. не указав единицу измерения.

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

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

Качественно составленный план - это уже половина дела. А для закрепления успеха вам может понадобиться еще кое-что.

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

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

У договоренности, которая становится явным правилом - сильно выше шансы быть выполненной.

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

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

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

И главное: не ретроспектива решает проблемы. Проблемы решают люди.