От выгорания команды до удвоения частоты релизов. Кейс Agile-коуча
Эта статья кратко описывает кейс работы 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, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.
При использовании информации из статьи ссылка на источник обязательна.
Больше кейсов, исследований, обучающих постов публикуем в нашем канале
В чем отличие Agile коучинга от командного коучинга?
Если вы не знакомы с терминами agile и коучинг, то одной статьи, скорее всего, не хватит, чтобы разложить все по полочкам. Но я постараюсь описать различия кратко и емко, чтобы было понятно даже тому, кто еще не сталкивался ни с одним из этих понятий.
Давайте вначале кратко определимся с терминами.
Agile коучинг
Agile — это философия мышления. Agile включает принципы и ценности, а также различные инструменты, фреймворки, методы и гибкие методологии (scrum, Kanban, LeSS и т.д.).
Если очень кратко Agile — это про управление рисками, гибкость и скорость. С помощью Agile вы будете стремиться делать именно то, что нужно рынку, делать это быстро и эффективно. Agile инструменты применимы как к одной команде, так и ко всей компании. Agile широко используется для гибкого управления проектами/продуктами.
Чтобы было больше представления о философии agile, я напомню о ценностях Аgile:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следованию первоначальному плану.
Agile говорит о том, что наивысший приоритет — это удовлетворение потребностей заказчика.
Больше о принципах Agile можно прочитать тут.
Agile применим там, где есть большая доля неопределенности, когда известные хорошие практики могут не приносить желаемый результат. По модели Кеневина, в разных системах мы должны действовать по-разному. Например, когда мы строим мост, мы знаем, как действовать, есть технологии — это, скорее всего, сложная система и здесь будут применимы хорошие практики. А вот, например, при создании нового ИТ продукта, мы можем сразу не знать, что именно будет востребовано рынком — это запутанная система, тут важно сначала провести эксперименты.
Agile применим именно в запутанных системах.

Agile коучингом можно назвать работу/взаимодействие agile коуча с командой, департаментом или в целом c компанией с целью непрерывного улучшения потока создания ценности для клиентов, снижая риски. Agile коуч может действовать в разных форматах: он может быть коучем, фасилитатором, учителем, консультантом.
Командный коучинг
В определении командного коучинга важны оба слова: и коучинг, и команда.
По официальному определению Международной Федерации коучинга, коучинг – это длящиеся партнерские отношения, которые помогают людям получить результаты в их жизни, карьере и бизнесе.
Коуч не дает советов, не консультирует и даже не предлагает решения. Коуч будет вашим партнером по размышлениям, поможет в рефлексии, задаст такие вопросы, которые продвинут вас к решению проблемы, заметит и вернет, что вы сами не замечаете.
Перейдем к команде. У команды в отличие от группы людей, есть или должна быть единая общая цель. Из всех определений командного коучинга, мне более близко то, которое дал Дэвид Клаттербак:
«Командный коучинг — помощь команде, используя рефлексию и диалог, призванная улучшить производительность и процессы».
Теперь мы знаем, что командный коучинг работает с командой, используя коучинговые компетенции, а также компетенции фасилитатора.
Какие задачи решают оба метода?
В целом, и agile коучинг и командный, на уровне команд могут решать одни и те же задачи:
- сформировать цели и миссию,
- наладить взаимодействие и процессы,
- помочь команде быть более эффективной,
- сплотить команду и т.д.
Но инструменты взаимодействия с командой будут разными.
В чем тогда разница?
Во-первых, в формате:
- командный коучинг это — коучинг плюс фасилитация, т.е. коуч будет работать вопросами, возвратами наблюдений и т.д.,
- а agile коучинг — консультирование, фасилитация и обучение.
Во-вторых, в сфере применения.
Важно, что Agile может быть применим не ко всем командам, а как писали ранее, к тем, которые действуют в запутанной среде, когда есть неопределенность и ранее известные решения уже не работают.
Решая проблему команды командный коуч будет исследовать проблематику вместе с командой, задавать им вопросы, будет способствовать развитию рефлексии и осознанности в команде; с помощью коучинга команда сама придет к решению своих задач. Не исключая, того что agile коуч тоже может обладать профессиональными коучинговыми компетенциями, он больше опирается в своей работе на инструменты и знания; он может непосредственно помогать настраивать в команде процессы, быть фасилитатором, консультантом.
Ниже краткая таблица, чтобы можно было быстро понять различия и сходства.

Что выбрать для своей команды?
Если ваша команда достаточно зрелая, готова открыто говорить, рефлексировать, обсуждать, договариваться и вы хотите сами найти то решение, которое подойдет именно вашей команде — выбирайте командный коучинг.
Если ваша команда недостаточно зрелая, если люди не готовы к открытым и даже уязвимым дискуссиям, и вы решаете задачу, связанную с недостаточной эффективностью, то agile коуч скорее всего вам поможет лучше.
Конечно, здесь нет одного правильного ответа, что вам выбрать. Скорее всего эффективными и полезными окажутся оба. Решать всегда вам.
Если вам сложно определить, какой инструмент подойдет, вы можете обратиться к эксперту, который поможет прояснить цели и даст рекомендации, или написать мне напрямую.
Автор статьи — Мария Сорока, agile coach, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.
При использовании информации из статьи ссылка на источник обязательна.