Впечатления: М. Лоффлер — «Ретроспектива в Agile»

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

— Норман Керт — «Ретроспектива проекта»

В данном случае было 100%-е попадание в ожидания от книги. Я ничего особенного от неё не ожидал, я ничего особенного от неё и не получил. Однако дочитал до конца с целью оценить, насколько она может быть полезна для новичков, чтобы понять, тащить ли её на работу, чтобы, например, рекомендовать коллегам.

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

В запуске инициативы по проведению ретроспектив очень часто встречается одна и та же проблема:

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

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

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

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

Инструменты системного мышления

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

— Что такое бар?
— Являются ли люди, сидящие здесь, частью бара?
— Можно ли считать пиво частью бара?
— Что происходит, когда я пью пиво? Это всё ещё часть бара?
— Если я возьму пиво на улицу, останется ли оно частью бара?
— Бар — это система? Если да, то какова цель бара?

Первый инструмент системного анализа — Causal Loop Diagrams. Наиболее наглядный пример использования мне попадался на сайте Agilix в статье Скрам-мастер как организационный коуч. Вот например усиливающаяся петля проблемы оттока кадров.

Практические советы для CLD

1. Всегда используйте существительные для названий переменных. Стрелки уже изображают глаголы.
2. Отдавайте предпочтение количественно измеримым переменным. Переменная с именем «ситуация» не имеет смысла. Её нельзя увеличить или уменьшить.
3. Всегда принимайте во внимание непреднамеренные эффекты наряду с запланированными. Например, увеличивая производство вы действительно получаете более высокую производительность (предполагаемый эффект), но одновременно результатом может быть стресс или снижение качества (непреднамеренный эффект).
4. Балансировочные петли обязательно имеют цель. Она всегда должна быть частью петли. Явное включение цели в CLD даёт понять, чего вы хотите достичь.
5. Если связь между двумя переменными требует слишком много объяснений, переименуйте переменные или вставьте промежуточный шаг. 

Второй инструмент, упоминаемый в книге, — построение Дерева Текущей Реальности (ДТР) из Теории Ограничений Систем (ТОС). Эффективность могу подтвердить своим опытом. Подробнее можно погрузиться, прочтя, например, «Критическую цепь» Э. Голдтратта (ну или что-нибудь Голдратта или с упоминанием Голдратта).

Модель ABIDE

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

• Attractors (аттракторы) — вещи, идеи или люди, на которые система реагирует положительно;
• Barriers (барьеры) — определяют границы системы — дедлайны, физические перегородки между комнатами и командами, определение того, кто часть команды, а кто нет, лищние посредники;
• Identity (идентичность) — роли и обязанности в системе. Дайте людям больше ответственности и вы измените их идентичность;
• Diversity (разнообразие) — различия между членами команды в системе;
• Environment (окружающая среда) — среда системы.

Целеполагание

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

Точное описание желаемых целей можно получить, ответив на следующие вопросы:

• Какова ваша цель? Чего вы хотите достичь?
• Как вы узнаете, что достигли цели? Что изменится? А что ещё?
• Что вы станете делать иначе, когда достигнете цели?
• Как другие люди узнают, что вы достигли цели?
• Как они будут реагировать на изменения?
• Что их реакция значит для вас?

Критерии цели.

• не вопрос, а позитивное заявление;
• не действие, а ситуация, подробно описанная и учитывающая соответствующие условия;
• не чувство, а что-то конкретное;
• лежит в сфере влияния команды;
• практична и измерима.

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

Вторая полезная составляющая книги — хорошо описанная структура ретроспективы (даже слишком хорошо, кажется много раз повторяется одно и то же). И много практических примеров её реализации от описания конкретных упражнений до целых сценариев.

Краткая ретроспектива

• Что вы сделали вчера такого, чем можно гордиться?
• Чем вы помогли другим?
• Теперь, когда вы знаете гораздо больше, что бы вы сделали по-другому?
• + опциональный вопрос «А что ещё?»

(можно использовать на стендапе)

Краткая ретроспектива, ориентированная на решение

Ещё понравился вариант «деятельной» ретроспективы, предполагающей решение конкретных [технических] проблем за час.

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

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

Трудности перевода

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

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

А книга, в целом, неплохая.