От выгорания команды до удвоения частоты релизов. Кейс Agile-коуча

Эта статья кратко описывает кейс работы agile коучей с реальной ИТ командой (внутренний продукт) от начала, включая валидацию запроса, сопровождения (реализация плана решения проблематики) до снятия метрик по результатам работы. Весь цикл занял около 4-5 месяцев.

Если вы не знакомы со всеми терминами, которые будут упоминаться в статье, можно обратить внимание на сам процесс работы с командой: подход к валидации проблемы, инструменты, стадии работы и подход к измерению результатов.

Из статьи вы узнаете:

• как валидировать проблематику и найти корневую причину
• как измерить успех/прогресс работы
• пошаговое описание кейса от снятия запроса до измерения результатов
• за счет чего получилось достичь результата

Какой был запрос

К нам пришли представители ИТ команды (ИТ лид и деливери менеджер) со словами: «у нас выгоревшая команда, помогите! Надо что-то делать с уровнем стресса и психологическим здоровьем команды; обстановка сложная: слезы, нервы, успокоительные.»

В ходе интервью мы выяснили, что у команды были следующие предпосылки обратиться к коучам:

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

Этапы работы agile коуча с командой/периметром

Ниже перечислены этапы работы с запросом.

1. Снятие запроса
2. Валидация проблематики
3. Согласование плана действия с заказчиком и метрик успеха
4. Сопровождение команды (непосредственно решение)
5. Измерение метрик прогресса и валидация результатов

Валидация проблематики

При работе с любым запросом на изменения важно выявить реальную проблему или причину болей заказчика или команды, поэтому этап валидации проблематики является одним из ключевых. Часто если не соблюдать такую очередность этапов работы с запросом, можно столкнуться как минимум с большим сопротивлением команды, а как максимум не получить нужный результат (или вообще получить противоположный желаемому результат, усугубить проблему). И если не работать с реальной проблематикой (которую еще нужно выявить), то есть риск, что после ухода коучей из команды, все может вернуться к состоянию как было «до».

Этап валидации проблематики включал в себя, в частности, интервью с заказчиком, командой и владельцем продукта.

Интервью с заказчиками

Самое первое, это интервью с теми, кто пришел к нам с запросом. Обычно помогают следующие вопросы:

• С чем пришли, с каким запросом (часто заказчик может говорить, что-то вроде «проведите нам ретро или «нужно сплотить команду)?
• Почему это проблема, как вы понимаете, что это проблема (по каким признакам)?
• Для кого это проблема?
• На что влияет эта проблема?
• А что еще замечаете?
• Как вы видите образ результата?
• На что должно повлиять решение этой проблемы (на какие результаты/показатели)?

Это всего лишь небольшая часть вопросов для интервью. И дальше все вопросы интервьюера будут зависеть от ответов и контекста.

Интервью с участниками команды и владельцем продукта

Далее мы сделали серию интервью с разными ролями в команде и поговорили с новым владельцем продукта.

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

На этом этапе мы спрашивали следующее:

• Расскажи, что сейчас наблюдаешь в команде
• Что сейчас не устраивает, что мешает работе?
• Что бы ты хотел, чтобы поменялось в команде/продукте?

Выявление корневой причины или диаграмма причинно-следственных связей

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

Если кратко, то корневыми причинами были:

1. Отсутствие четкого видения продукта и требований к продукту.
2. Команда не управляла ожиданиями стейкхолдеров, т.е. не могла достоверно пообещать что-то сделать в назначенные сроки, и не понимала, что важно для стейкхолдеров и пользователей.
3. У команды были размыты роли и отсутствовали понятные процессы внутри команды.
4. Отсутствие прозрачного процесса поставки ценности.

К тому же, в данном кейсе были и более системные проблемы (проблемы, которые лежат не в зоне влияния команды). Этот момент мы пока опустим и опишем именно работу с проблематикой команды.

Сокращенную диаграмму вы можете увидеть на картинке ниже.

Как мы измерим прогресс и успех (метрики)

Для измерения результатов мы взяли следующие метрики:

• Частота релизов команды (1 раз в 3 месяца)
• Опрос команды (шкалирование/оценка). Вопросы составляли исходя из контекста и проблематики (средний балл 6,4 из 10):
• Оцени, насколько тебе интересно работать в команде.
• Оцени, насколько тебе достаточно поддержки от коллег и руководителя.
• Оцени свое состояние с точки зрения наличие ресурса и сил.
• Оцени, насколько полезны для тебя командные встречи (этот вопрос добавили т.к. участники команды на интервью говорили о длинных и неэффективных встречах).
• Оцени, насколько эффективно для тебя проходит процесс планирования и груминга.
• Частота обратной связи от пользователей (0 за последний квартал)
• И несколько продуктовых метрик (количество подписок в проде и среднее время подключения)

Можно было бы еще взять Lead time, но команда не вела достоверно jira, чтобы можно было измерить этот показатель.

Очная сессия – как окончательная валидация проблематики и начало работы с командой

Этапом окончательной валидации проблематики и одновременно началом работы с командой стала очная сессия со всей командой. Лично мне кажется, такой заход в команду самым эффективным с точки зрения создания доверия как с коучем, как внутри команды, так и между лидером и командой.

На очной сессии команда может осознать и обсудить проблематику и даже частично закрыть некоторые вопросы (например, как в этом кейсе – вопросы, касающиеся ясного видения продукта).

У нас было 2 дня и структура встречи выглядела следующим образом:

День 1

1. Знакомство/разминка (как оказалось, многие очно видели друг друга первый раз)
2. Ожидания от встречи
3. Блок про эмоции (фасилитируемый формат и фрейм)
4. Ретроспектива (что хорошо/что я ценю, что нам нужно изменить/что мешает, идеи как это исправить, план действий)
5. Закрытие: что было самым важным

День 2

1. Видение продукта, роудмеп и метрики продукта – все это представляет владелец продукта. Далее вопросы и обратная связь от команды
2. Карта стейкхолдеров продукта и план коммуникаций с каждой группой стейкхордеров
3. Выработка критериев приоритезации бэклога
4. Командные правила
5. Закрытие

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

Какой был план действий

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, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.

Если вы хотите цитировать эту статью, то используйте ссылку на источник.