Эта статья кратко описывает кейс работы agile коучей с реальной ИТ командой (внутренний продукт) от начала, включая валидацию запроса, сопровождения (реализация плана решения проблематики) до снятия метрик по результатам работы. Весь цикл занял около 4-5 месяцев.
Если вы не знакомы со всеми терминами, которые будут упоминаться в статье, можно обратить внимание на сам процесс работы с командой: подход к валидации проблемы, инструменты, стадии работы и подход к измерению результатов.
Из статьи вы узнаете:
- как валидировать проблематику и найти корневую причину
- как измерить успех/прогресс работы
- пошаговое описание кейса от снятия запроса до измерения результатов
- за счет чего получилось достичь результата
Какой был запрос
К нам пришли представители ИТ команды (ИТ лид и деливери менеджер) со словами: «у нас выгоревшая команда, помогите! Надо что-то делать с уровнем стресса и психологическим здоровьем команды; обстановка сложная: слезы, нервы, успокоительные.»
В ходе интервью мы выяснили, что у команды были следующие предпосылки обратиться к коучам:
- уход лидера команды – владельца продукта (лидер перешел на позицию выше)
- управление командой на время было передано одному из участников команды – релиз менеджеру
- большая авария на продукте, которая повлекла длинные аварийные конференции и стресс для всей команды
- уход части команды (часть ушла в другой продукт, часть- уволилась)
- конфликты в команде и потеря мотивации
Этапы работы agile коуча с командой/периметром
Ниже перечислены этапы работы с запросом.
- Снятие запроса
- Валидация проблематики
- Согласование плана действия с заказчиком и метрик успеха
- Сопровождение команды (непосредственно решение)
- Измерение метрик прогресса и валидация результатов
Валидация проблематики
При работе с любым запросом на изменения важно выявить реальную проблему или причину болей заказчика или команды, поэтому этап валидации проблематики является одним из ключевых. Часто если не соблюдать такую очередность этапов работы с запросом, можно столкнуться как минимум с большим сопротивлением команды, а как максимум не получить нужный результат (или вообще получить противоположный желаемому результат, усугубить проблему). И если не работать с реальной проблематикой (которую еще нужно выявить), то есть риск, что после ухода коучей из команды, все может вернуться к состоянию как было «до».
Этап валидации проблематики включал в себя, в частности, интервью с заказчиком, командой и владельцем продукта.
Интервью с заказчиками
Самое первое, это интервью с теми, кто пришел к нам с запросом. Обычно помогают следующие вопросы:
- С чем пришли, с каким запросом (часто заказчик может говорить, что-то вроде «проведите нам ретро или «нужно сплотить команду)?
- Почему это проблема, как вы понимаете, что это проблема (по каким признакам)?
- Для кого это проблема?
- На что влияет эта проблема?
- А что еще замечаете?
- Как вы видите образ результата?
- На что должно повлиять решение этой проблемы (на какие результаты/показатели)?
Это всего лишь небольшая часть вопросов для интервью. И дальше все вопросы интервьюера будут зависеть от ответов и контекста.
Интервью с участниками команды и владельцем продукта
Далее мы сделали серию интервью с разными ролями в команде и поговорили с новым владельцем продукта.
Важно изначально выстроить доверительный диалог, сказать, почему мы пришли, что уже нам удалось узнать, с каким контекстом мы пришли. Создание доверия очень важно. Необходимо постараться понять боли или точки неудовлетворенности участников команды, прежде чем предлагать решение.
На этом этапе мы спрашивали следующее:
- Расскажи, что сейчас наблюдаешь в команде
- Что сейчас не устраивает, что мешает работе?
- Что бы ты хотел, чтобы поменялось в команде/продукте?
Выявление корневой причины или диаграмма причинно-следственных связей
На каждом интервью мы записываем каждую мысль на стикеры на доске миро. Далее группируем их и строим диаграмму причинно-следственных связей, т.е. стараемся проставить зависимости между озвученными проблемами. В этой статье я не буду подробно останавливаться на том, как ее строить. Если хотите в этом разобраться, вы можете найти эту информацию в открытых источниках, или, например, в книге «Системное мышление для руководителей» от Денниса Шервуда.
Если кратко, то корневыми причинами были:
- Отсутствие четкого видения продукта и требований к продукту.
- Команда не управляла ожиданиями стейкхолдеров, т.е. не могла достоверно пообещать что-то сделать в назначенные сроки, и не понимала, что важно для стейкхолдеров и пользователей.
- У команды были размыты роли и отсутствовали понятные процессы внутри команды.
- Отсутствие прозрачного процесса поставки ценности.
К тому же, в данном кейсе были и более системные проблемы (проблемы, которые лежат не в зоне влияния команды). Этот момент мы пока опустим и опишем именно работу с проблематикой команды.
Сокращенную диаграмму вы можете увидеть на картинке ниже.
Как мы измерим прогресс и успех (метрики)
Для измерения результатов мы взяли следующие метрики:
- Частота релизов команды (1 раз в 3 месяца)
- Опрос команды (шкалирование/оценка). Вопросы составляли исходя из контекста и проблематики (средний балл 6,4 из 10):
- Оцени, насколько тебе интересно работать в команде.
- Оцени, насколько тебе достаточно поддержки от коллег и руководителя.
- Оцени свое состояние с точки зрения наличие ресурса и сил.
- Оцени, насколько полезны для тебя командные встречи (этот вопрос добавили т.к. участники команды на интервью говорили о длинных и неэффективных встречах).
- Оцени, насколько эффективно для тебя проходит процесс планирования и груминга.
- Частота обратной связи от пользователей (0 за последний квартал)
- И несколько продуктовых метрик (количество подписок в проде и среднее время подключения)
Можно было бы еще взять Lead time, но команда не вела достоверно jira, чтобы можно было измерить этот показатель.
Очная сессия – как окончательная валидация проблематики и начало работы с командой
Этапом окончательной валидации проблематики и одновременно началом работы с командой стала очная сессия со всей командой. Лично мне кажется, такой заход в команду самым эффективным с точки зрения создания доверия как с коучем, как внутри команды, так и между лидером и командой.
На очной сессии команда может осознать и обсудить проблематику и даже частично закрыть некоторые вопросы (например, как в этом кейсе – вопросы, касающиеся ясного видения продукта).
У нас было 2 дня и структура встречи выглядела следующим образом:
День 1
- Знакомство/разминка (как оказалось, многие очно видели друг друга первый раз)
- Ожидания от встречи
- Блок про эмоции (фасилитируемый формат и фрейм)
- Ретроспектива (что хорошо/что я ценю, что нам нужно изменить/что мешает, идеи как это исправить, план действий)
- Закрытие: что было самым важным
День 2
- Видение продукта, роудмеп и метрики продукта – все это представляет владелец продукта. Далее вопросы и обратная связь от команды
- Карта стейкхолдеров продукта и план коммуникаций с каждой группой стейкхордеров
- Выработка критериев приоритезации бэклога
- Командные правила
- Закрытие
Итогом очной сессии стало общее понимание/осознание проблематик команды, которые обсудили на ретроспективе, также команда открыто поговорила и выразила свои эмоции. Важным было и то, что команда обсудила видение, стратегию продукта и приоритеты работы. Также команда ушла с планом действий по улучшению процессов и ответственными после ретроспективы, которые они сформировали самостоятельно.
Какой был план действий
1. Работа с владельцем продукта: обратная связь по команде, помощь в формировании понятного видения продукта. На очной встрече так же привлекли руководителя Владельца продукта – владельца домена, чтобы получить от него обратную связь и синхронизировать ожидания от команды.
2. Визуализация процесса создания потока ценности, настройка доски jira и критериев перехода задач из статуса в статус (definition of ready и definition of done).
Это один из ключевых этапов. На картинке ниже визуализация потока создания ценности внутри команды (красными стикерами отмечены области, где были наибольшие проблемы в процессах).
В результате формирования критериев приемки для каждого этапа удалось сформировать прозрачные правила и артефакты, например, у команды появились шаблоны для user story, которые включали в себя не только описание задачи, критерии приемки, функциональные и нефункциональные требования, но даже такие вещи, как зависимости на другие продукты/команды. На этом этапе также увидели, за счет чего зависали релизы. Работа над процессами команды позволила ускорить частоту релизов с одного в 3 месяца до одного в 1,5 месяца. В команде релиз менеджер был отдельно от команды, сам формировал все артефакты для change комитета, почти никто не принимал решения по выпуску релизов. А в результате формирования критериев приемки на каждом этапе получилось распределить подготовку артефактов по всему процессу, договориться о прозрачных правилах и структуре документов команды на одном источнике, а также структурировать процесс выпуска релиза.
3. Помощь команде в настройке командных событий, в особенности планирования. Также мы проводили для команды ретроспективы. Впоследствии, команда могла самостоятельно проводить все командные события без внешних фасилитаторов.
4. Помощь в разборе бэклога и приоритизации задач
5. Помощь в определении ответственности между лидами продукта: владельцем продукта, ИТ лидом, деливери менеджером и релиз менеджером
6. Помощь в проведении демо и получении обратной связи от пользователей. Впоследствии, команда начала собирать обратную связь на регулярной основе.
Какие agile (и не только) практики и инструменты мы использовали:
- Практики Kanban: визуализация процесса, критерии приемки и готовности, настройка jira доски, практики управления потоком создания ценности
- Настройка событий: планирование, груминг, дейли и демо
- Коучинг и консультирование команды и владельца продукта
- Системный подход
- Evidence Based Management — подход к измерению ценности
Результаты и метрики по результатам работы
В результате, команда действительно стала командой:
- команда стала работать вместе на один общий результат,
- команда стала фокусироваться на результате и приоритетах,
- стало больше взаимопомощи и общения (даже неформального),
- стали заботятся об эмоциональном состоянии,
- после ухода лидера в другой продукт, смогли работать самостоятельно без руководителя.
Вот некоторые комментарии команды на общем заключительном ретро о том, что получилось: «работали как команда», «вышли из стресса», «договорились о процессе работы», «стали менее токсичными».
А теперь посмотрим на метрики до и после.
Как видно, все метрики изменились в лучшую сторону. Самое основное, конечно, это результат работы самого продукта: увеличилось кол-во подписок в проде и увеличилась частота выпуска релиза. Конечно, ценно не само увеличение релизов, а это увеличение вместе с тем, что команда делает то, что нужно (а на это мы повлияли тем, что согласовали видение продукта со стейкхолдерами и настроили обратную связь с пользователями).
Из того, что нельзя измерить, но можно наблюдать – это атмосфера в команде и самостоятельность работы команды.
А что касается психологического климата в команде вот комментарий ИТ лида: «Сильно все упростилось, команда комфортно себя чувствует. Атмосфера в команде стала лучше; повысилась эффективность встреч; бэклог стал понятнее и прозрачнее; стали лучше понимать друг друга».
За счет чего получилось?
- создание доверительного взаимодействия с командой
- выявления корневых причин проблемы, а не работа со следствием
- создания мотивации к изменениям у участников команды и вовлечение их в процесс изменений
- поддержка и вовлечение лидов команды
- взращивания ответственности и компетенций внутри команды
- нацеленность на единый результат (общая цель (продукта) у команды)
- сопровождение команды (фасилитация, обратная связь и т.д.)
А самое главное в том, что все изменения были не навязаны и происходили не директивно за счет того, что мы решали реальную проблему команды, а не натягивали практики agile ради самих практик. Это очень важный этап — идти от конкретной проблемы, найти корневую причину проблемы и работать уже с ней.
Автор статьи — Мария Сорока, agile coach, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.
При использовании информации из статьи ссылка на источник обязательна.
