Один из этапов эволюции команды — развитие навыка работы над ошибками и командного улучшения рабочего процесса. Групповая рефлексия критически необходима как и в умении слаженно противостоять нештатным ситуациям так и более грамотно проводить планирование рабочего времени под задачи.
Немаловажно понимать роль SCRUM-мастера или координатора в процессе внедрения и проведения ретроспективы. В первую очередь важны люди, и если не принимать этот факт во внимание, то можно забыть о развитии команды.
О самом опыте:
Цель: внедрить практики SCRUM в рабочие процессы команды. Сроки: год с момента формирования кросс-функциональных команд.
Для первого опыта было необходимо выбрать одну или несколько практик из фреймворка и внедрить без особой подготовки, попутно вылавливая ошибки, проводя работу над ними. Из описания очень здорово взлетает ретроспектива.
Следовало изучить различные видео и текстовую документацию по структуре и сути ретроспективы. Подготовить короткую презентацию на команду с целью предварительного ознакомления без какой либо подготовки. С учетом того, что часть команды, так или иначе имели представления работы в Agile.
Короткий вебинар на команду не занял более получаса. Настроение в итоге было разным: кто-то скептически относился к практике, кому-то стало интересно, были и те, кто резко негативно отзывался о идее, аргументируя тем, что практика направлена больше на поиски виноватого, но никак не на улучшение процессов. Итог тем не менее был определен большинством, и все-же решили попробовать.
Не буду расписывать что такое ретроспектива, из каких частей она состоит и какие инструменты используются для каждой части. Этой информации достаточно в больших количествах, и, доступной даже бесплатно. Затрону только два: ESVP в открытии и Feedback smiles в закрытии соответственно. Выбор на инструменты пал с учетом того, что команда распределена, а ретроспектива проводится онлайн, и необходимо было понимание насколько успешно внедряется практика. Ответы в открытии и обратная связь в конце ретроспективы позволяли выявить сотрудников с которыми следовало провести митинг 1-1 с целью более подробного разъяснения сути ретроспективы.
Итак ESVP (ИПОЗ). Кем ты себя позиционируешь на первой ретроспективе:
И — Исследователи (Explorer) стремятся открыть для себя новые идеи и знания. Они хотят узнать все, что можно, об итерации/релизе/проекте.
П — Покупатели (Shopper) рассматривают всю доступную информацию и будут счастливы отправиться домой с одной новой полезной идеей.
О — Отпускники (Vacationer) не заинтересованы работать в ходе ретроспективы, но рады отвлечься от ежедневной рутинной работы. Впрочем, на какое-то время они тоже могут почувствовать интерес к групповому взаимодействию.
З — Заключенные (Prisoner) чувствуют, что их заставили здесь находиться, и предпочли бы заняться чем-то другим.
На открытии только один из сотрудников указал, что ощущает себя насильно приглашенным на активность (Prisoner). Остальные девять распределились между исследователем (Explorer) и покупателем (Shopper), что уже вселяло надежду на более менее успешное проведение.
Обратная связь (Feedback smiles) уже показала более интересные результаты относительно открытия. Обсуждения в основной части ретроспективы были достаточно плодотворными в выявлении инициатив на улучшение, которые мы собирали в отдельный файлик, трансформировавшийся в дальнейшем в лог ретроспективы. Выделил три смайла:
Доволен, нейтрален и совершенно не устраивает соответственно. Помимо визуального оформления настроения, было предложено указать свой отзыв и в письменном виде по желанию. Вот некоторые комментарии из результатов:
Нужно какое-то голосование, гранулирование проблем. Чтобы общим составом обсуждались только общие проблемы.
Может быть дело в том, что первый раз, но очень много не-общей информации и воды. Если и поднимать темы на таких митингах, то они должны быть касающиеся 70% людей. Для меня из всего перечисленного важно было только то, что воркфлоу покрывает не все статусы задачи, но это можно за 3 минуты обсудить:) С другой стороны в частное нет смысла вдаваться глубоко, так как у разработчиков свои митинги, например, для этого
Огонь! Поддержу!
Сам же Feedback выглядел так:
Как можно заметить — мнения разделились ровно в половину. Из десяти человек пятерым необходимо было проведение митингов 1-1 для более точного понимания их скептицизма.
Нужно сказать что данная схема помогла настроить всю команду на единый лад работы с ретроспективой. Но даже в том случае было опасение что рано или поздно проведение ретроспективы сойдет на нет.
Чтобы ретроспектива работала, необходимы результаты в виде улучшения рабочих процессов. Можно сколь угодно внедрять практики, но без видимых результатов они только лишь усложняют работу. Множество времени, сил и труда уходит на поддержание в активном состоянии внедренных практик как самого SCRUM-мастера, так и всей команды. Причем улучшения в результате проведения первой ретроспективы не должны быть обязательно глобальными и сильно заметными. Достаточно простых договоренностей, добавляющих слаженности в работе. Главное, чтобы улучшения были и они работали. Не менее важная роль всех членов команды в обсуждении и выборе решений. Команда сама должна выбирать какие из проблемных участков нужно исправить. Улучшение рабочих процессов, упрощение их там где это необходимо мотивирует всех на продолжение использование практики.
Как только появились первые результаты работы в групповой рефлексии вся команда была позитивно настроена и каждый отзывался о ретроспективе как о лучшей командной практике. Что сам, без колебаний, так же поддержу.
Как только команда собрана, даже если она еще не имеет единого вектора направления — нужно внедрять ретроспективу. Будет ли эта встреча оффлайн или онлайн не имеет особого значения. Сложнее проводить онлайн, так как живое общение позволяет сразу же увидеть мотивированных на результат людей и тех, кто пришел ради смены вида деятельности. Но даже на онлайн встрече, используя различные техники фасилитации, можно получить достаточно хорошие результаты командного обсуждения.
Собираясь командой в офисе с whiteboard стикерами и маркерами время может пролетать незаметно и в таком случае проведение ретро будет занимать не менее часа, растягиваясь почти на все рабочее время. Онлайн сложнее — мало кто высидит час, особенно если не участвует в обсуждении (что бывает даже при хорошей фасилитации). Исходя из этого сбор информации и голосование по инициативам требующих решения решили проводить заранее в отдельном документе (google spreadsheet). В течении одного спринта собирались инициативы и проводилось голосование. Выявляли наиболее существенную и более общую для всей команды инициативу. А на самой встрече обсуждались варианты решения инициативы, внедрение и контроль за исполнением. Такой подход позволяет сократить время онлайн встреч. И, так как команда состояла из различных должностей, и должности не были смазаны или обезличены, то, к примеру, инициативы аналитиков не откликались у разработчиков, когда инициативы разработчиков так же не полностью касались QA. Было опасение в отсутствии мотивации участия той или иной должности в обсуждении. Тогда голосование помогало направить всю команду на общий результат.
Дальнейшее внедрение SCRUM контролировалось уже ретроспективой. Статус апдейты, дэйли стендапы, демки, планирование и прочие инструменты и практики обсуждались на рестроспективе всей командой. Что позволило в кратчайшие сроки брать на вооружение инструмент и выплевывать его если он не прижился, либо от него нет видимых улучшений в работе команды.
Что еще хотелось упомянуть с опытом проведения ретроспектив:
- Мы не называем проблемы проблемами. Негативная окраска настраивает команду на защитную реакцию, которая впоследствии может вызвать желание уйти в защиту и в поиски отговорок, без мотивации решить проблему. Инициатива — пожалуй лучшая находка в нашем случае.
- Проведение ретроспективы ретроспектив так же улучшает практику, заменяя или дополняя заезженные инструменты свежими идеями.
- Полезно ранжировать фасилитацию ретры другими мотивированными членами команды. Отдав на откуп выбор инструментов и регламента выступления.
- SCRUM-мастеру или координатору достаточно брать ответственность за выбор решения, в случае возникновения споров, но никак не продвигать свое как истину в последней инстанции.
- Принятые решения стоит записывать в командном wiki.
Полезные ссылки:
- Борис Вольфсон — Эффективные ретроспективы
- Agile Retrospectives: Making Good Teams Great
Да, введение нового в работу всегда занимает какое-то время. Даже наши клиенты при первичном использовании платформы могут немного путаться, но благодаря поддержке быстро внедряют agile в работу :)