Недостатки постоянных ретроспектив в Agile

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

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

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

  • Меняйте место проведения: иногда смена обстановки может сделать ретроспективу свежей снова.
  • Разные фасилитаторы: чередуйте тех, кто ведёт ретроспективу, чтобы привнести новые перспективы.
  • Новые активности: включайте разные активности, такие как «Продолжай, останавливай, начинай» или «Роза, шип, бутон», чтобы поддерживать интерес.

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

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

  • 30 минут на сбор данных: сбор проблем и отзывов от команды.
  • 5 минут базовой группировки: группировка похожих проблем и голосование за самые важные.
  • 30 минут анализа причин и действий: глубокий анализ выбранных проблем и создание конкретных действий.

Ещё одной распространённой проблемой является то, что действия, предпринятые после ретроспективы, часто остаются невыполненными. Это может произойти по нескольким причинам:

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

Для решения этой проблемы убедитесь, что действия соответствуют критериям SMART (конкретные, измеримые, достижимые, релевантные, ограниченные по времени) и интегрированы в бэклог спринта. Вот как это можно сделать:

  • Публично размещайте действия: чётко отображайте действия на стене задач/истории.
  • Напоминайте в ежедневных стендапах: регулярно напоминайте команде об этих действиях во время ежедневных стендапов.

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

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

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

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

Чтобы обеспечить психологическую безопасность:

  • Проводите ретроспективы наедине: убедитесь, что присутствуют только члены команды.
  • Анонимность обратной связи: используйте анонимные механизмы обратной связи, чтобы поощрять честный вклад.
  • Установите правила: чётко сформулируйте правила для ретроспективы для поддержания доверия и уважения.

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

Вот блок-схема, которая поможет решить, как часто проводить ретроспективы:

Заключение

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

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