В девятом выпуске подкаста Kanban Talks Алекс Цыбульник, Kanban Coach, беседует с Владиславом Могильниковым — Agile-коучем и основателем образовательного проекта Time2IT. В центре обсуждения — причины провалов agile-трансформаций и конкретный кейс из практики Владислава, где сопротивление изменениям оказалось сильнее заявленных целей.
О себе и ключевых принципах
Владислав работает в сфере agile уже более шести лет, в числе его работодателей — Спортмастер, Ренессанс Кредит и Renault. Свою деятельность он выстраивает на трёх ключевых принципах:
1. Начни с себя.
Прежде чем критиковать или предлагать изменения другим, важно задать себе тот же вопрос. Владислав придерживается этой позиции не только в работе, но и в повседневных привычках — от отказа от пиратства до сортировки мусора.
2. Непрерывное развитие.
Владислав цитирует Льюиса Кэрролла: «Нужно бежать со всех ног, чтобы только оставаться на месте». Для него это о постоянном росте — как личном, так и организационном.
3. Совпадение по ценностям.
Владислав принципиален в выборе компаний: если ценности не совпадают, он отказывается от сотрудничества, независимо от условий. Так, он отклонил предложение от компании из сферы ставок, посчитав её деятельность неэтичной.
О трансформации: от запроса до сопротивления
К Владиславу обратилась компания, переживавшая смену владельца: крупная корпорация приобрела стартап и передала задачу — «трансформироваться в соответствии с agile-культурой головной компании». Однако конкретные цели при этом не были сформулированы.
Первичная диагностика
Владислав начал с выявления проблем:
- Отсутствие прозрачных целей трансформации,
- Низкий уровень культуры: политические игры, отсутствие обратной связи, сопротивление ошибкам,
- Хаос в разработке и слабый Discovery-процесс,
- Недостаточная компетентность Product Owners.
Для диагностики использовались:
- One-to-one встречи с представителями разных департаментов,
- Частичный опрос по методике Gallup Q12,
- Модель из книги Tribal Leadership (оценка уровня «племенной» культуры).
Реакция на предложенные меры
После аудита Владислав предложил стратегию трансформации:
- Введение культуры обратной связи,
- Повышение прозрачности,
- Формирование продуктовых команд,
- Запуск Discovery-процессов с конкретными метриками,
- Упор на ценность, а не на задачи.
Изначально всё было поддержано, но на практике началось скрытое сопротивление:
- Решения затягивались,
- Предложения отвергались как «нестандартные»,
- Один из ключевых элементов — команда Discovery — не был одобрен,
- Бюджет на найм дополнительных скрам-мастеров «вдруг» исчез,
- Лояльные топ-менеджеры были вынуждены покинуть компанию.
Как принимались решения до и после
До начала трансформации решения принимались на совещаниях, где приоритет получал тот, кто громче заявлял о важности своей задачи. При этом:
- Не использовались скоринговые модели,
- Не применялись метрики влияния (RICE, ICE, ROI),
- Решения принимались на основе субъективного мнения CPO, CTO и помощников CEO.
Предложение внедрить команду Discovery (с участием нескольких продукт-оунеров, аналитика, дизайнера и архитектора) было отклонено из-за того, что «так не делают».
«Нам сказали быть Agile». Почему трансформация не задалась
Когда компания живёт в привычном хаосе, сотрудники просто привыкают к этому. Но стоит появиться внешнему требованию «быть Agile» — и всё рассыпается. Владислав Могильников, Agile-коуч и основатель Time2IT, рассказывает, с чем столкнулась одна из команд после того, как их стартап купила крупная компания.
До трансформации: как всё было устроено
Процессы были организованы «по старинке»: команды были разбиты по функциям — Android, iOS, системный анализ, тестирование, веб. Над продуктами работали продукт-оунеры, у которых не было своей команды — только задачи. Они получали команды от CPO или генерального, создавали тикеты в Jira, после чего все задачи собирались на встречи руководства, где происходило ручное распределение ресурсов. Это приводило к постоянным задержкам: приоритеты прыгали, задачи вставали в очередь, релизы переносились.
Разработчики, аналитики, тестировщики жили в перманентном стрессе. Приоритеты могли меняться за один день, и никто не объяснял, почему нельзя бросить задачу на полпути. Люди выгорали, увольнялись. Те, кто оставался, всё чаще говорили: «Я просто хожу за зарплатой», и саботировали изменения, даже если на словах соглашались.
Пример скрытого саботажа
Саботаж был в основном скрытым. Один из примеров: на встрече принимается решение, все говорят «да», но после этого человек идёт к генеральному директору и говорит, что идея — провальная. Инициатива тормозится, потому что «кто первый пожаловался — тот и прав». Так была заблокирована идея Discovery-команды: хотя рабочий процесс был прописан, показатели эффективности определены, а команда должна была сократить time-to-market, отдельные участники делали вид, что ничего не поняли, и подрывали инициативу извне.
Discovery-команды: эволюция или революция?
На первый взгляд, внедрение Discovery-команд могло бы показаться революцией: команды с новыми ролями, процессами, взаимодействием. Но на деле это была эволюция. Люди и раньше работали вместе, просто не назывались «командой», не имели нормальных процессов и не мерили эффективность. Владислав собрал их вместе, дал прозрачные правила, и они начали работать как команда.
Основная цель была — не ускориться, а навести прозрачность, наладить коммуникации и сократить количество эскалаций на верхний уровень. Успех был не в скорости, а в том, что людям стало проще работать вместе и решать задачи без лишней бюрократии.
Зачем вообще понадобилась трансформация?
До покупки стартап жил своей жизнью: не торопился, зарабатывал, и всем было ок. После покупки крупной компанией всё изменилось. Головная организация спустила требование: «Вы должны быть Agile». Без чёткого объяснения, зачем, без критериев успеха — просто указание.
Это был не запрос на трансформацию изнутри, а директива извне. Поэтому всё началось с хаоса. Люди не понимали, зачем меняться, но знали, что иначе не получат бюджет.
Как контролировали «Agile-ность»
Контроль был, мягко говоря, субъективным. Представители головной компании просто приходили и разговаривали с сотрудниками. Владислав мог бы сказать, что всё хорошо — но он выбрал честность:
«Я не за видимость, я за пользу. Если соврёшь, потом всё равно всплывёт. Это игра в долгую».
Метрики (Cycle Time, Time-to-Market) никто особо не собирал, но ожидалось, что когда-нибудь их всё же предъявят. Поэтому даже неофициальные рекомендации «было бы хорошо, если бы…» быстро превращались в «обязательно».
Выводы
Agile — не панацея и не бумажка с чек листом. Это инструмент, который помогает наладить процессы, когда есть внутренняя готовность меняться. Когда трансформация навязывается сверху, без понимания ценности, начинается хаос, саботаж и недоверие. Но даже в таких условиях можно выстроить работающую систему — если подходить к изменениям как к эволюции, а не революции.
