Scrum — одна из самых популярных моделей в мире Agile-разработки. Но почему именно она заняла лидирующие позиции? Что в ней такого особенного? В этом выпуске Kanban Talks Илья Павличенко и Алексей Цыбульник разбираются, как Scrum стал «дефолтом» в мире гибких методологий.
Scrum как фреймворк по умолчанию
Scrum сегодня — это как паспорт Agile: его изучают первыми, его чаще всего требуют в вакансиях, и он регулярно мелькает в обучающих программах. На вопрос «почему?» эксперты дают несколько ключевых ответов:
- Масштабное распространение через обучение. Основным драйвером популярности стал именно образовательный рынок. В начале 2000-х, когда Scrum только набирал обороты, его начали активно преподавать и сертифицировать — на фоне отсутствия конкуренции и более сложных альтернатив (например, XP).
- Семантическая простота. Scrum предлагает понятные роли: скрам-мастер, владелец продукта, команда. Эти роли легко воспринимаются и запоминаются. А спринты дают чёткую структуру — «две недели, и вот тебе результат».
- Чёткая упаковка. Scrum хорошо «продаётся»: он оформлен как законченный продукт — компактный, со своими артефактами, ритуалами и терминологией.
Scrum как инструмент развития и контроля
Интересно, что изначально Scrum задумывался не как инструмент жёсткого управления, а как фреймворк для роста команды. Однако на практике его часто используют для усиления контроля — особенно когда менеджмент воспринимает Scrum как способ «ускорить» работу или «наладить дисциплину».
«Scrum снаружи выглядит как очень хороший инструмент для измерения и давления на команду», — говорит Алексей Цыбульник.
Тем не менее, сам фреймворк предлагает возможности для развития: ретроспектива, прозрачность, инкремент. Но чтобы их использовать осознанно, нужно быть готовыми к изменениям — а это уже требует определённой зрелости.
Scrum — это как шахматы
Одна из метафор, которую приводят спикеры — сравнение Scrum с шахматами:
- В шахматах есть чёткие правила, фигуры и доска — но выигрывает не тот, кто просто знает правила, а тот, кто умеет думать стратегически.
- То же самое и со Scrum: можно формально соблюдать все ритуалы, но без глубокого понимания сути эффекта не будет.
Эта метафора подчёркивает важную мысль: Scrum — не просто набор практик, а система обучения мышлению и взаимодействию. Он может быть мощным инструментом саморазвития команды — если использовать его именно так.
Как избавиться от ярлыка «адепта LЕSS»?
Чтобы уйти от образа фаната одного подхода, важно делать три вещи:
- Образование — проводить тренинги, выпускать книги (например, с Эзарио).
- Публичность — участвовать в мероприятиях, говорить об этом открыто.
- Маркетинг себя как системного консультанта, а не евангелиста конкретного фреймворка.
В диалоге с компаниями важно снимать напряжение. С самого начала нужно проговаривать: цель — не «протащить LESS любой ценой», а понять стратегические цели компании и уже под них подобрать подход.
«Я не с LESS к вам пришёл — я с вопросами: какая у вас стратегия? Какие организационные способности нужны: скорость, адаптивность, предсказуемость?.. И под это мы подберём обучающие практики.»
В этой логике отпадает сам по себе спор, что лучше — LESS или SAFe:
«Они оба хороши. У каждого — своя область применения. Главное — интересы клиента и компании.»
Когда использовать Scrum, LESS или SAFe?
Начать стоит с диагностики:
- Какова стратегия компании: хочет ли она быть адаптивной?
- Насколько компания подвержена конкуренции?
- Есть ли поддержка топов?
- На каком этапе жизненного цикла находится продукт: стартап, рост или стабильная фаза?
Если продукт стабилен, конкуренции немного, и организация не готова к резким изменениям, то SAFe может подойти. Почему?
«SAFe позволяет „масштабироваться“ без ломки управления: раздал ярлычки, сделал PI-планинг — и всё вроде бы работает. Это удобно, но это не адаптивная система.»
А вот Scrum и LESS — это скорее про демасштабирование, упрощение, снятие лишнего.
Один продукт — один бэклог
Важная мысль:
«Scrum применяется к продукту, а не к команде.»
В идеале — один продукт, один бэклог. Даже если над продуктом работают тысяча человек. Управление бэклогом — это управление спекуляциями (или «опционами»), а управление потоком — уже уровень классов обслуживания.
Для крупных организаций иногда добавляют Discovery Kanban до бэклога, чтобы снизить когнитивную нагрузку. Этим управляет команда владельцев продукта, а команды становятся «фичефабриками» с end-to-end ответственностью.
«В идеале, конечно, как в СБП (Система быстрых платежей) — и Discovery, и Delivery делает одна команда. Это ракета.»
Условия для успеха трансформации
Факторы, которые встречаются во всех успешных кейсах:
1. Жесткая поддержка топов. Настоящая, безапелляционная. Пример:
«Гендир был готов уволить всех, кто сопротивляется. Я был против, но такой настрой — показатель.»
2. Процент волонтеров. Замеры на пилотах помогают понять: кто готов? Кто уходит? Это ключевая метрика.
3. Поддержка снизу. Особенно важна в больших организациях. Пример:
В одной розничной трансформации активно отслеживают процент вовлечённых сотрудников, аккуратно переводят тех, кто не хочет участвовать, в другие подразделения.
«Если есть поддержка сверху и снизу — всё остальное дело техники.»
Scrum в материальном производстве?
Да, бывает. Например, компания Mighty Buildings — они печатают дома на 3D-принтерах. Работали с ними не по LESS, а по Nexus, потому что:
«Во время диагностики стало понятно: команда просит минимизации вмешательств.»
Это ещё раз подтверждает подход: во главе — не фреймворк, а контекст и цели организации.
Хотите внедрить эффективные управленческие практики и не «тащить» фреймворк ради галочки?
Специалисты Neogenda помогут вам найти подход, который действительно сработает в контексте вашей компании. Мы сотрудничаем с лидерами рынка — Tinkoff, Яндекс, Авито, Сбер, Билайн — и уже обучили более 5 000 сотрудников. Подберем решения, основанные на реальном опыте и современных практиках. Запишитесь на бесплатную консультацию в Zoom, чтобы найти способы сделать вашу команду ещё эффективнее.
