Я продолжаю серию статей про гибкий образ мысли. В прошлых статьях мы обсуждали взаимоотношения с заказчиками и приоритизацию требований, а в этой расскажу про одно из важных мероприятий в 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. Книжка, кстати, хорошая, рекомендую - в русском переводе, говорят, тоже есть.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
