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

При использовании информации из статьи ссылка на источник обязательна.

Больше кейсов, исследований, обучающих постов публикуем на нашем канале

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

При использовании информации из статьи ссылка на источник обязательна.

Больше кейсов, исследований, обучающих постов публикуем на нашем канале