В новом выпуске подкаста Алекс Цыбульник, Unbound Coach, беседует с Ильёй Павличенко, скрам-тренером из Scrum.ru. Тема разговора — Scrum, его масштабирование, отличие от других подходов и почему он стал самым популярным фреймворком гибкой разработки.
Что такое Scrum — простыми словами
Илья любит метафоры. Scrum он сравнивает с системой тренировок для бизнеса. Чтобы развить гибкость, нужно качать «организационные мышцы» — и Scrum даёт такую возможность. Он помогает адаптироваться к рынку, быстро тестировать гипотезы, запускать продукт в условиях неопределенности.
Другая метафора — озеро. Прозрачная вода позволяет увидеть камни на дне — дисфункции в организации. Scrum «спускает уровень воды» за счёт ограничений. И дальше выбор: убирать камни или снова залить водой и жить в иллюзии порядка. Scrum — не причина проблем, а способ их обнажить.
Ни Scrum, ни XP, ни Kanban не гарантируют успех или провал. Это лишь инструменты. Успех зависит от зрелости команды и смелости изменений.
Почему Scrum стал таким популярным?
- Эмпирическая база. В основе — пятилетнее исследование японских и американских компаний, опубликованное в статье The New New Product Development Game (HBR, 1986). Scrum не изобретали на пустом месте — его принципы реально работали у лучших команд.
- Маркетинг и сертификации. В 2002 году Кен Швайбер с коллегами основал Scrum Alliance и запустил сертификацию (CSM, CSPO). Это дало структуру, узнаваемость и чувство принадлежности — появилась «айдентика» Scrum-сообщества.
- Баланс структуры и свободы. Scrum предлагает ясные роли и процессы, но не перегружает команду обязательными практиками. Есть свобода — а значит, чувство контроля и ответственности у команд.
- Сильные личности у истоков. Кен Швайбер и Джефф Сазерленд — не просто методологи, а настоящие мыслители. Если бы в менеджменте вручалась Нобелевка, они были бы в числе первых лауреатов.
Сертификация как идентичность нового племени?
Алекс подмечает: сертификация CSM — это не только маркетинг, но и механизм формирования сообщества. Scrum стал частью идентичности. Как когда-то ROUP требовал знаний и структур, Scrum дал людям ощущение причастности, нового способа мышления.
Илья соглашается: да, это создало лагеря, сообщества, идеологические разногласия. Как, например, у Дэвида Андерсона, сторонника Kanban, открытого критика Scrum. Но это не плохо — это часть развития. Разные подходы — часть одного большого движения.
Сертификация — не добро и не зло. Она помогает фреймворку развиваться, создаёт видимость структуры, но не должна становиться самоцелью.
Как запустить «ракету»: что делает трансформации успешными
Когда в компании слишком много бэклогов, а каждый продукт живёт своей жизнью — система теряет гибкость. Да, менять направление можно, но только радикально и раз в квартал. В таких условиях управлять не продуктом, а потоком становится куда важнее. Особенно, если в бэклогах лежат не просто задачи, а опционы — то, что ещё предстоит исследовать.
Одно из решений — Discovery Kanban до бэклога. Так можно снять когнитивную нагрузку с команд: не перегружать разработчиков, не превращать кросс-функциональность в выгорание. А дальше — фича-фабрика: Discovery —> Backlog —> Delivery. Идеальная модель — когда одна команда делает и Discovery, и Delivery. Так работает, например, СБП (система быстрых платежей), и работает как ракета.
Почему NSPK взлетает
Все успешные кейсы трансформации, как показывает практика, строятся на трёх опорах:
- Жёсткая и безусловная поддержка топов. Настоящая. Когда CEO говорит: «Я уволю всех, кто не готов меняться» — и ты понимаешь, что он не шутит. Это не про увольнение, а про готовность идти до конца. Таких людей видно сразу, с ними можно делать большое дело.
- Высокий процент волонтёрства. Когда люди сами выбирают участвовать. В одной продуктовой группе все остались, в другой — девять человек вышли. Но это нормально, трансформация — не для всех. Главное — мягко, с уважением, перераспределить, где возможно, и не сопротивляться естественному отбору.
- Плотная работа с сопротивлением и препятствиями. Поддержка совета директоров, возможность быстро решать вопросы, менять процессы взаимодействия между подразделениями, где это нужно. Без этого масштабируемый Scrum или любое изменение упирается в стены.
NSPK — именно такой кейс. Уже несколько лет команды Скрамру работают с ними, и это одна из лучших трансформаций за всё время.
А что с материальным производством?
Можно ли применять Scrum, если у тебя не софт, а бетон и 3D-принтеры? Можно — и это уже пробовали.
Пример: Mighty Buildings
Компания печатает дома на 3D-принтерах. Проект начинался с Nexus, потому что важно было сохранить текущие команды. Люди устали от изменений, и это нужно было учитывать. В итоге удалось выстроить процесс с учётом ограничений:
- команды не полностью кросс-функциональны;
- высокий цикл изменений;
- тяжёлая интеграция;
- очень дорогая цена переделок.
Здесь главный вызов — невозможность частого инкремента. Дом не построишь за спринт. Значит, нужно находить, чем можно управлять: например, печатать панель, пока другая команда делает для неё материал. Такой подход требует продвинутого планирования, заглядывания на 3–4 спринта вперёд, иногда даже диаграмм Ганта.
Плюс — нужно использовать канбан. Идеальная связка: Scrum или Nexus в середине, по бокам — канбан, который оборачивает весь поток создания ценности. Слева — Discovery, справа — поддержка, сопровождение, маркетинг.
А что с классами обслуживания?
Да, их можно и нужно применять. Даже если в Scrum это не всегда называется напрямую. Например, в бэклоге может лежать:
- Регуляторика — фиксированный срок и скоуп.
- Run-задачи — поддержка, инфраструктура.
- Исследование — Discovery и спекуляции.
Разные классы — разные правила приоритезации. И это позволяет управлять потоком уже не только до, но и после точки принятия обязательств. Главное — не забывать про проактивную работу с бэклогом, заранее учитывать зависимости, особенно в сложных продуктах с длинным циклом.
Управленческие решения — и готовность их принимать
Когда компания переходит к масштабируемому Scrum, вопрос не только в фреймворке. Главное — насколько организация готова к системным управленческим изменениям. Илья Павличенко подчеркивает: внедрение не случится без пересмотра HR-политик, без изменения формулы мотивации и принципов развития специалистов.
Сначала — слэк-тайм, потом — трансформация
Одна из ключевых проблем всех трансформаций — отсутствие ресурса на изменения. Все горит, спринты бегут, задницы в огне. В таких условиях ожидать, что команда начнет меняться — наивно. Нужно официально выделить время на обучение. Например, в Raiffeisen, когда SME-группа переходила в LeSS, до 40% времени люди тратили на освоение новых подходов. Без этого — невозможно.
При этом важно откровенно говорить людям: «Да, вы полгода будете в провале. Да, KPI не покажут прироста. Но бонусы сохранятся, и ваша задача — учиться».
Без этой договорённости менеджеры будут продолжать развивать узкие специализации и тормозить переход к кросс-функциональности. В результате — саботаж изменений на уровне матрицы, когда функциональный менеджер сопротивляется, потому что теряет контроль и зону влияния.
Разрушение матрицы: это не страшно, если честно
Scrum предполагает, что команды координируются сами. Больше не нужны фиче-менеджеры, фейковые продакты и толпы проектных координаторов. Это требует перестройки всей логики управления.
Один из подходов — сократить количество руководителей и передать им ответственность за развитие людей вширь, а не вглубь. Один лидер — 50 разработчиков. Они могут идти в разное направление, быть частью разных команд, и это нормально.
Но вот вопрос: готова ли организация на это?
SAFe: компромисс для неготовых
Если Scrum кажется слишком радикальным — можно пойти по пути меньшего сопротивления. SAFe даёт более мягкий вход. Там каждый найдёт себе место — даже те, у кого «полковничьи погоны». Поэтому уровень сопротивления будет ниже, но и адаптивность — тоже.
Зато честно. И именно честность — главный ресурс трансформации.
Пять решений, которые нужно принять
Если вы всё-таки хотите масштабируемый Scrum, приготовьтесь к следующим вопросам:
- Готовы ли вы изменить систему оплаты?
- Выделите ли вы до 40% времени на обучение?
- Согласны ли вы на разрушение матричной структуры?
- Понимаете ли, кто будет координировать команды и как?
- Готовы ли вы к потере «контроля» со стороны функциональных менеджеров?
Ответ «да» хотя бы на часть этих вопросов — уже шаг вперёд. Ответ «нет» — тоже честно. Главное — чётко понимать, что Scrum невозможен без этих решений.
«У нас не настоящий Scrum — и это нормально»
Илья приводит кейс: в одном банке его пригласили разобраться, почему трансформация буксует. После трёх часов разговора HR-директор честно сказал: «Спасибо. Я теперь понимаю, что у нас не настоящий Scrum. И у нас его не будет. Но хотя бы теперь понятно, почему не работает. И мне стало легче».
Это честный диалог. Он стоит дороже, чем любое красиво оформленное «внедрение». Потому что лучше узнать правду сразу, чем потратить год на иллюзии.
Быть честными друг с другом — главное условие
В завершение — призыв. И к собственникам, и к менеджерам, и к agile-коучам, и к скрам-мастерам.
➡️ Если вы менеджмент — честно скажите, на что вы готовы.
➡️ Если вы коуч — объясните, какие изменения стоят за каждым фреймворком.
И тогда вместо agile-цирка появится настоящее взаимодействие. А если изменений не будет — ничего страшного. Просто не стоит обманывать себя.
