Каталог решений - Думать некогда, трясти надо — или что такое ретроспектива в Agile

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

На мой взгляд, именно рефлексия “как мы работаем” и корректировка курса при необходимости и является одним из ключевых отличий подхода Agile от подхода “тяп-ляп”, который я описывала в  статье Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? 

Почему это важно?

Идея, что надо оценивать результативность своей работы и вносить коррективы, не нова. Вряд ли Уолтер Шухарт и Эдвард Деминг действительно были первыми, кто ее высказал, но именно им удалось озвучить ее наиболее громко.
Деминг, в поте лица трудившийся в середине 20 века на благо и процветание японской промышленности, активно совершенствование агитировал (хотя здесь за отсутствием идеи самоуправления улучшение вменяется в обязанность не "команде", как в Agile, а "руководству"): “Улучшайте каждый процесс. Улучшайте постоянно, сегодня и всегда все процессы планирования, производства и оказания услуг. Постоянно выискивайте проблемы для того, чтобы улучшать все виды деятельности и функции в компании, повышать качество и производительность и, таким образом, постоянно уменьшать издержки. Непрерывное улучшение системы, включающей в себя разработку и проектирование, поставку комплектующих и материалов, обслуживание и улучшение работы оборудования, методов управления и организации, подготовку и переподготовку кадров — есть первейшая обязанность руководства.”
 
Принцип учета обратной связи используют практически в любой здравомыслящей организации. На производстве при обнаружении проблем применяют цикл Шухарта-Деминга: планируй (Plan), делай (Do), проверяй (Check), применяй (Act). В том смысле, что сначала — придумывай способы решения проблем (Планируй), потом реализуй их (Делай), проверяй что получилось (Проверяй), и действуй на основании полученной информации (Применяй полученные в ходе проверки знания).
Авторы Свода знаний по управлению проектами PMBOK, по сути, положили в его основу тот же самыйцикл и прикрутили к нему инициацию в начале и завершение в конце. Мой коллега Иван Селиховкин превратил эту картинку в симпатичного удава (только не начинайте опять обсуждать, с головы ли проект должен начинаться или наоборот). В-общем, все говорят про усовершенствования.

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

Зачем это надо?

Ретроспектива — это специально организованное мероприятие, где важно создать атмосферу для обмена мнениями и сбора информации. Большинству нормальных людей (особенно русских)  рефлексировать непривычно. “Итак всё понятно, чего тут обсуждать?..”. Но, практика показывает, что при разумной организации процесса (“наша кошка тоже сначала не любила пылесос, а потом — ничего, втянулась”) люди постепенно привыкают, и рефлексировать становится естественным. Хотя, честно скажу, что все команды, с которыми я имела дело, были готовы рефлексировать гораздо меньше, чем призывают делать, например, американские коллеги. Так что читая западные книжки делайте поправку на культурные различия. И еще, кстати, у нас совершенно нет традиции измерять. Что угодно — продуктивность, количество ошибок, динамику и т. п. Типичный ответ “и так понятно”. Что именно “и так понятно” — при этом у всех могут быть разные версии. Но провести измерения — нееет, это лишнее. Но я отвлеклась от основной темы.

Что даст вашей команде специально организованное размышление “как улучшить работу”? Возможность осознать, что именно не работает и как это можно исправить. Наше мышление устроено таким образом, что мы не можем одновременно и думать и действовать. И для того, чтобы увидеть “большую картину” (big picture) происходящего, нужно остановиться и посмотреть на нее со стороны. А то получится как в старом анекдоте:

Решили как-то сравнить прапорщика с обезьяной. Посадили их в две одинаковые комнаты с деревом и бананом на дереве. Обезьяна потрясла, потрясла дерево — банан не падает. Видит палка в углу стоит, зацепила банан палкой, сидит довольная и лакомится.
Прапорщик же трясёт пальму, трясёт… Час трясёт, два трясёт. Ему говорят: "товарищ прапорщик, ну вы подумайте немного", на что тот отвечает: "Чего тут думать! Трясти надо!"

При каких условиях у вас ничего не получится?

Я размышляла, стоит ли добавить этот пункт в мою статью. Позитивное мышление, и всё такое. Но, тем не менее, из песни слова не выкинешь… Итак, у вас врядли получится что-то кроме "поговорили и разошлись", если…

• Ваша команда замотивирована не на результат, а на имитацию бурной деятельности.
• Люди не решаются высказывать свою точку зрения, так как нет атмосферы доверия и сотрудничества.
• Наиболее острые проблемы лежат за пределами зоны ответственности команды, и руководство не готово изменять процессы компании.
• У ведущего категорически не хватает авторитета для поддержания рамок.
• Ведущий уже знает ответы на все вопросы, и мнение группы ему не особо интересно.
• Фокус внимания при обсуждении сместился на вопрос “Кто дурак?” или “Почему я не виноват?”, а не на вопрос “Что нам делать дальше?”

В какой момент следует проводить ретроспективы? 

• Если у вас  есть четко ограниченные итерации с демонстрацией продукта заказчику — как, например, в Scrum —  то ретроспективы логично проводить сразу после. 

Если нет — допустим, вы работаете по Канбан-системе, или вообще сочетаете работу “по водопаду” с “гибкими методами” — то ретро можно проводить в любой момент, когда вам это удобно. Например:

• Если у вас состоялся релиз
• Если вы сделали логически законченный кусок работы
• Если у вас давно не было ретроспектив (уже несколько недель)
• Если вы чувствуете, что застряли и вам нужно сдвинуться с мертвой точки

Как можно проводить ретроспективы и как сделать ретроспективу интересной?

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

1. Устанавливаем рамки

Договариваемся о правилах игры, о правилах взаимодействия (их полезно выработать совместно).
Практика показывает, что очень важно на начальном этапе, во-первых, всех посадить вместе (никакого “я останусь за своим рабочим местом, мне и отсюда всё прекрасно слышно”), во-вторых, чтобы каждый хоть что-нибудь сказал (хотя бы назвал свое имя или сказал “мне пока нечего сказать, я пропускаю очередь” — это поможет молчаливым участникам включиться.
Как можно геймифицировать? Мне нравится для запуска ретроспективы игра ESVP (Explorer — Исследователь или Экспериментатор, Shopper — Покупатель, Vacationer — Отдыхающий, Prisioner — Заключенный — по-русски можно использовать аббревиатуру ЭЗОП). 
В начале каждому из участников предлагаем анонимно написать на листочке (букву или номер), в какой роли он  на сегодняшней ретроспективе: пришел искать решения проблемам (Исследователь/Экспериментатор), посмотреть, чего интересненького дадут, просто отвлечься от работы, или ему пришлось сюда припереться, так как неизбежно. 
Ведущий перемешивает листочки, чтобы было непонятно, кто что ответил, и записывает результаты на доске. 
Что здесь ценно? Мы видим картинку, насколько команде важно, что происходит. Те, кому не важно (в первую очередь “Заключенные”) видят уважение к своей позиции.
Можно предложить им после перерыва покинуть это собрание — в конце концов, насильно мил не будешь. Если “заключенных” большинство, ретроспективу лучше провести максимально оперативно и конструктивно ))),

2. Собираем информацию

В начале ретроспективы важно возобновить в памяти, что произошло за последнее время. Это важно, во-первых, чтобы вспомнить, во-вторых, чтобы сместить фокус внимание с фактов на отношение к ним. Можно вспомнить ключевые проблемы, с которыми столкнулась команда.
Как можно геймифицировать? Красивая техника для этого — Линия времени, когда участники вспоминают события и размещают их на линии времени.
Еще интересный подход — техника Mad, Sad, Glad (Бесит-Печалит-Радует), когда участников просят вспомнить (можно в парах), какие события за обсуждаемый период времени их Взбесили-Опечалили-Порадовали. Дальше можно их разместить на трёх частях доски. И используем собранную информацию для следующего этапа ретроспективы.

3. Генерируем идеи

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

4. Решаем, что делать

После обсуждения высказанных вариантов надо принять решения, какие именно изменения мы внедрим. Типичная ошибка неофитов в Agile — попытка изменить “всё и сразу”.  “У нас с вами не получилось сделать полезный пользователю продукт, не работает самоуправление, куча претензий к качеству, отклонение по срокам — давайте это всё в следующий раз улучшим” — такой подход, к сожалению не работает. Нужно выбрать несколько, с одной стороны, важных, а с другой — посильных моментов, и работать именно над ними. 
Как можно геймифицировать? 
Мне нравится использовать разные техники приоритизации (см. мою предыдущую статью Приоритизировали, приоритизировали, да не выприоритизировали… , я там немного про это рассказывала).

5. Завершаем ретроспективу

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

-В позапрошлом году мы посадили 100 Га пшеницы, но все пожрал проклятый хомяк! В прошлом году мы посадили 200 Га пшеницы, и снова все пожрал проклятый хомяк! А в этом году мы посадим 500 Га пшеницы, и пусть подавится этот проклятый хомяк!
 

Как можно геймифицировать?

Хорошая техника — термометр. Отслеживаем, где мы сейчас находимся, и куда можем двигаться дальше.

Здесь я рассказала рекомендуемую структуру ретроспективы, и привела только один пример, как можно это делать на практике. Подробное описание структуры ретроспективы и большое количество разных игр и активностей можно найти в книжке Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers), авторы  Esther Derby, Diana Larsen, Ken Schwaber. Книжка, кстати, хорошая, рекомендую — в русском переводе, говорят, тоже есть. 
 

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах