ЛК
Меню
О Scrum без прикрас: разговор с Ильей Павличенко

О Scrum без прикрас: разговор с Ильей Павличенко

В новом выпуске подкаста Алекс Цыбульник, 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 взлетает

Все успешные кейсы трансформации, как показывает практика, строятся на трёх опорах:

  1. Жёсткая и безусловная поддержка топов. Настоящая. Когда CEO говорит: «Я уволю всех, кто не готов меняться» — и ты понимаешь, что он не шутит. Это не про увольнение, а про готовность идти до конца. Таких людей видно сразу, с ними можно делать большое дело.
  2. Высокий процент волонтёрства. Когда люди сами выбирают участвовать. В одной продуктовой группе все остались, в другой — девять человек вышли. Но это нормально, трансформация — не для всех. Главное — мягко, с уважением, перераспределить, где возможно, и не сопротивляться естественному отбору.
  3. Плотная работа с сопротивлением и препятствиями. Поддержка совета директоров, возможность быстро решать вопросы, менять процессы взаимодействия между подразделениями, где это нужно. Без этого масштабируемый 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, приготовьтесь к следующим вопросам:

  1. Готовы ли вы изменить систему оплаты?
  2. Выделите ли вы до 40% времени на обучение?
  3. Согласны ли вы на разрушение матричной структуры?
  4. Понимаете ли, кто будет координировать команды и как?
  5. Готовы ли вы к потере «контроля» со стороны функциональных менеджеров?

Ответ «да» хотя бы на часть этих вопросов — уже шаг вперёд. Ответ «нет» — тоже честно. Главное — чётко понимать, что Scrum невозможен без этих решений.

«У нас не настоящий Scrum — и это нормально»

Илья приводит кейс: в одном банке его пригласили разобраться, почему трансформация буксует. После трёх часов разговора HR-директор честно сказал: «Спасибо. Я теперь понимаю, что у нас не настоящий Scrum. И у нас его не будет. Но хотя бы теперь понятно, почему не работает. И мне стало легче».

Это честный диалог. Он стоит дороже, чем любое красиво оформленное «внедрение». Потому что лучше узнать правду сразу, чем потратить год на иллюзии.

Быть честными друг с другом — главное условие

В завершение — призыв. И к собственникам, и к менеджерам, и к agile-коучам, и к скрам-мастерам.

➡️ Если вы менеджмент — честно скажите, на что вы готовы.

➡️ Если вы коуч — объясните, какие изменения стоят за каждым фреймворком.

И тогда вместо agile-цирка появится настоящее взаимодействие. А если изменений не будет — ничего страшного. Просто не стоит обманывать себя.