Agile-подход к управлению изменениями: минимизация сопротивления сотрудников

Статья Академии Бизнес-Психологии о том, как Agile-подход поможет минимизировать сопротивление сотрудников в условиях изменений

«Сама потребность в адаптации не нова. Еще Бенджамин Франклин говорил “Переставая меняться, вы перестаете жить”; новыми являются другие факторы: частота, с которой нам приходится меняться, скорость с которой нужно двигаться, сложность и изменчивость среды, в которой мы обитаем» —  Джон Коттер

В условиях динамичного бизнес-окружения организации сталкиваются с необходимостью постоянных изменений. Почему управление изменениями так важно? А вы помните компанию Kodak или телефоны Nokia? Часто изменения и быстрая адаптация к новому — это вопрос выживания. Однако до 70% трансформаций терпят неудачу из-за сопротивления сотрудников:

  • Исследование McKinsey (2015): Компания указывала, что около 70% трансформаций не достигают заявленных целей, а одной из ключевых причин называлась сопротивляемость сотрудников и недостаток вовлеченности.
  • Работа Джона Коттера:  В книге «Leading Change» (1996) профессор Гарварда писал, что 70% инициатив изменений проваливаются из-за человеческого фактора: страхов, отсутствия коммуникации, слабого лидерства.

Agile трансформации бизнеса требовали существенных изменений: от изменения мышления и изменения оргструктур до изменения процессов. Я как Agile-коуч поделюсь инструментами и подходами, которые мы как агенты изменений применяем на практике.

Понимание сопротивления изменениям

В чем самая большая сложность проведения изменений? В том, что мы не знаем как? В том, что часто изменения касаются большого количества людей? А может в том, что изменения это долгий процесс?

Самый большой вызов в управлении изменениями — это сопротивление людей, которые проводят изменения или которых эти изменения непосредственно затрагивают. Сопротивление — естественная реакция на неопределенность, проявляющаяся в страхе потери контроля, недостатке информации или недоверии к руководству. 

Причины проявления сопротивления: 

  • Страх перед новым
  • Ощущение угрозы стабильности
  • Непонимание целей изменений и др.

Формы проявления: 

  • Поведенческие: саботаж, пассивность
  • Эмоциональные: тревога, раздражение
  • Рациональные: критика решений на основе фактов. 

Agile-подход к управлению изменениями

Вообще не очень правильно говорить, что есть agile подход к управлению изменениями. На самом деле мы используем принципы и ценности agile, и они помогают в том числе и управлять изменениями.

  • Итеративность вместо «водопадного» планирования (да, не только в разработке, но и в подходе к изменениям)
  • Акцент на людях и взаимодействии (принципы Agile)
  • Смелость (ценность Agile)
  • Быстрая обратная связь и адаптация

Но также мы часто используем в своей работе 2 подхода: ADKAR (индивидуальный фокус) и 8 шагов Коттера (организационный уровень) — дополняют Agile-подход, обеспечивая системность и учет человеческого фактора.

ADKAR: модель для работы с индивидуальными изменениями

Модель ADKAR для работы с индивидуальными изменениями статья Академии Бизнес-Психологии

Цель: Поэтапно подготовить сотрудников к изменениям, устранив личные страхи и барьеры. 

Модель, разработанная Джеффри Хайяттом, включает пять шагов:

  1. Awareness (Осознание необходимости):
    Цель: Объяснить, почему изменения необходимы. На мой взгляд, это самый сложный этап.
    Пример: Проведение встреч с данными о рыночных трендах или внутренних проблемах компании.
  2. Desire (Желание участвовать):
    Цель: Сформировать личную мотивацию сотрудников поддержать изменения.
    Инструменты: Показать личные выгоды (карьерный рост, упрощение работы), вовлечение через обратную связь, работа с мотивацией сотрудников.
  3. Knowledge (Знания):
    Цель: Обеспечить обучение новым навыкам и процессам. 
    Пример: Тренинги, обучение, инструкции, менторство.
  4. Ability (Способность применять):
    Цель: Помочь сотрудникам внедрить знания в повседневную работу.
    Методы: Практические воркшопы, поддержка коучей, тестовые задания, обратная связь.
  5. Reinforcement (Закрепление):
    Цель: Предотвратить возврат к старым привычкам.
    Инструменты: Система поощрений, регулярная обратная связь, признание успехов. 

Преимущество ADKAR — точечная работа с сопротивлением на уровне каждого сотрудника.

8 шагов Коттера: системный подход к организационным изменениям

8 шагов Коттера: системный подход к организационным изменениям статья Академии Бизнес-Психологии

Цель: Провести трансформацию на уровне всей организации, изменив культуру и процессы. 

Модель Джона Коттера (Harvard Business School) включает:

  1. Создать ощущение срочности. Мотивировать команды действовать, показав риски бездействия (например, угрозу конкуренции). 

  2. Сформировать руководящую коалицию. Объединить лидеров, которые будут продвигать изменения (включая неформальных лидеров). 

  3. Разработать стратегию и видение. Четко сформулировать, куда и как движется организация. 

  4. Коммуницировать видение. Донести цели до всех сотрудников через истории, встречи, символы (например, обновленный лозунг компании). 

  5. Расширить полномочия сотрудников. Убрать бюрократические барьеры, дать командам свободу экспериментировать.
     
  6. Достичь краткосрочных побед. Укрепить доверие через быстрые результаты (например, успешный пилотный проект за 3 месяца).

  7. Закрепить и углубить изменения. Интегрировать изменения в процессы, обновить KPI и систему оценки. 

  8. Внедрить изменения в культуру. Сделать новые подходы частью ДНК организации (например, через ритуалы, обучение новых сотрудников). 

 Сила модели Коттера —  акцент на системности и долгосрочной трансформации.

Комбинация моделей

ADKAR и 8 шагов Коттера дополняют Agile-подход, закрывая «слепые зоны» управления изменениями: 

  • ADKAR помогает преодолеть индивидуальное сопротивление
  • Коттер обеспечивает стратегическую целостность
  • Agile дает гибкость и скорость

Используйте ADKAR для работы с сопротивлением на микроуровне, шаги Коттера — для макропланирования, а Agile — для итеративного выполнения.

Кейс как не надо (реальный пример из моей практики)

В нашем случае в команду на 80+ человек пришел новый лидер. Он запланировал сделать изменение оргструктуры и частично изменить назначение ролей и сделать из отдельных сотрудников команды.

Как он начал работать со своими подчиненными? Он сделал формальную ретроспективу, на которой команда открыто и доверительно поделилась своими проблемами. Потом он взял эти проблемы как предпосылки к своим идеям по изменениям и вынес на всех свое решение.

Как думаете, что он сделал не правильно?

Вот несколько ВРЕДНЫХ советов, о том, как не надо проводить изменения:

  1. Если вы команда менеджеров или лидер команды, просто решите, как и что нужно менять. Мнение людей, которых касаются изменения, вас не должны интересовать. Решение принято, есть дорожная карта и мы идем.
  2. Не нужно рассказывать предпосылки изменений, текущую проблематику и корневые причины.
  3. Не формулируйте гипотезы, все решения уже приняты и их нужно исполнять
  4. Не имейте четких критериев успеха изменений, не смотрите на метрики и не имейте образа результата изменений. Чем более расплывчатый результат, тем лучше 
  5. Если все-таки люди станут задавать вопросы, ведите диалог формально, тяните время, скоро они смиряться и перестанут задавать вопросы
  6. Подведите первые итоги месяцев через 9, когда изменения уже случаться и все устаканиться, так уже не будет дороги назад.

А теперь как надо

В результате объединения всей разработки одного бизнес направления создали новый трайб с новым лидером. 

Трайб в Agile — это группа взаимосвязанных команд, сформированная вокруг определённого продукта или бизнес-цели и отвечающая за бизнес-результат.

Трайб объединил в себе несколько команд разных продуктовых направлений. Этот лидер пришел к Agile-коучам и мы смогли начать изменения «правильно».

1. Лидер выступил перед своей командой минус 1 и рассказал, что послужило причиной объединения трайба, рассказал о текущих проблемах и своем видении решения. Он также обозначил, что его решение это направление работы и дальнейшие изменения будут согласовываться с командой. Лидер рассказал о видении направления бизнеса и метрических целях.

2. Вместе с Agile-коучами на команду лидера и его минус 1 были проведены сессии по формированию value стримов для эффективной нарезки команд.

Value Stream (поток создания ценности) в Agile — это последовательность шагов, которые необходимы для преобразования идеи в конечный продукт или услугу, доставляемую клиенту.

3. Для команды лидеров трайба было проведено практическое обучение Agile-инструментам и          практикам (Agile for Leaders)

4. На протяжении всей работы Agile-коучи сопровождали изменения и помогали применять и адаптировать под контекст трайба новые процессы.

Этот кейс еще в процессе, но применение этих шагов ускорило процесс формирования команд  и минимизировало сопротивления сотрудников.

И в заключение

Agile-подход трансформирует управление изменениями, превращая сопротивление в ресурс для роста. Итеративность, прозрачность и вовлечение снижают страх и повышают вовлеченность. Организациям стоит начать с малого:

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

 Чем мы можем помочь в рамках этой темы:

  • проведение обучающие воркшовоп по Agile,
  • проведение воркшопов по управлению изменениями, командной мотивации и формированию команд,
  • консультации по организационному дизайну и проведение сессий по value stream,
  • проведение страт сессий и сессий по целеполаганию,
  • консультации по проведению изменений,
  • диагностика системных проблем периметра.

Если у вас остались вопросы, напишите автору.

Автор статьи — Мария Сорока, agile coach, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.

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

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

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

Автор статьи — Мария Сорока, agile coach, командный коуч и коуч лидеров, эксперт Академии Бизнес-Психологии.

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

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

В чем отличие Agile коучинга от командного коучинга?

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

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

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