Scrum в растущей компании: как адаптировать методологию под реальные процессы

В 2019 году РМС запустила две пилотные Scrum‑команды. Сегодня элементы методологии используют не только для управления задачами, но и для квартального планирования, развития сотрудников и решения проблем между подразделениями.

Две команды вместо масштабного внедрения

Для обучения пригласили бизнес‑тренера и эксперта по Scrum Олега Исаева. Уже в сентябре первые команды начали работать по новой системе: отдел региональных продаж и маркетинг.

Команды для пилота выбрали не случайно. Маркетинг возглавляла Юлия Егорова — она сама тяготела к продуктовому мышлению и была готова пробовать новые подходы, поэтому одной из первых поддержала идею и начала погружать в Scrum свою команду. Отдел региональных продаж оказался одной из самых отзывчивых и гибких команд в компании — с них было легко начинать перемены.

Роль первого Scrum‑мастера взяла на себя сотрудница отдела ОРП Анна Игумнова. Она проводила стендапы и другие встречи, совмещая новую функцию с работой менеджера по продажам.

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

У РМС не было отдельного подразделения, которое отвечало бы за внедрение методологии. Такой подход снизил риск формального внедрения. Сотрудники могли сразу проверить, помогают ли короткие встречи, доска и спринты управлять работой или только добавляют новые обязанности.

Практический вывод: начинать лучше не со всей компании, а с одного‑двух подразделений. Пилот быстро показывает, подходит ли методология конкретным процессам и какие правила придётся адаптировать.

Встречи записывали на видео и разбирали с коллегами из GRASS

Команды смотрели, не превратился ли стендап в отчёт руководителю, говорят ли участники о реальных препятствиях и заканчивается ли ретроспектива конкретными решениями.

Разбор собственных встреч оказался полезнее абстрактного обучения. На записи сразу было видно, где команда уходит в детали, почему встреча затягивается и кто фактически принимает все решения.

Этот подход можно использовать и без внешнего консультанта. Достаточно периодически приглашать на встречу опытного фасилитатора или Scrum‑мастера из другой команды.

Для анализа встречи достаточно пяти вопросов:

1. Понимают ли участники, зачем собрались?
2. Обсуждают ли они общий результат или только перечисляют задачи?
3. Поднимаются ли реальные проблемы?
4. Завершается ли встреча решениями?
5. Возвращается ли команда к этим решениям позже?

Если на большую часть вопросов ответ отрицательный, встреча проводится по расписанию, но не выполняет свою функцию.

Как одна ретроспектива запустила «посты Спасибо»

Оказалось, что значительная часть работы была сделана при поддержке коллег из других подразделений. Кто‑то оперативно подключился к задаче, кто‑то помог изменить процесс, кто‑то передал важную информацию.

На доске появились стикеры с благодарностями: кому, за что и какой вклад повлиял на результат. HRD Валерия Плотникова решила не оставлять их внутри команды и опубликовала общий пост в корпоративной ленте.

Так в РМС появились командные «посты Спасибо».

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

Рабочая благодарность должна быть конкретной. Вместо «спасибо всем за помощь» лучше написать:

Благодарим команду логистики за оперативное изменение графика отгрузки. Благодаря этому заказ ушёл клиенту без переноса срока.

Такая формулировка не только отмечает человека, но и показывает, какое действие компания считает ценным.

На exit‑интервью по наблюдению HR ответ на вопрос «Как ты считаешь, твой труд ценился?» часто связывают именно с культурой благодарности. У человека формируется ощущение, что их вклад был замечен и назван вслух, а не растворился в общих командных показателях.

Физическая доска перестала соответствовать масштабу компании

Первая Scrum‑доска РМС помещалась на стене небольшого офиса в городе Шахты. Для небольших команд этого было достаточно: все участники работали рядом и видели движение задач. Сотрудники вручную передвигали карточки, осваивали стендапы и учились говорить не только о выполненной работе, но и о проблемах.

По мере роста компании появились новые проекты, подразделения и удалённые участники. Физические доски постепенно сменились виртуальными.

Переход позволил сотрудникам из разных городов работать с одним источником информации, видеть ответственных, сроки и препятствия. Но цифровой инструмент сам по себе не сделал процессы прозрачными.

Если команда не обновляет статусы задач — не отмечает, что задача взята в работу, поставлена на паузу или завершена, — виртуальная доска быстро превращается в архив. Без регулярной актуализации статусов и без встреч, как в РМС, реальное положение дел снова приходится выяснять в чатах и на совещаниях.

Чтобы задачи на доске оставались живыми и рабочими, в ней должны быть основными критериями:

• понятный результат;
• срок;
• подробное ТЗ;
• отчёты о статусе работы;
• если задача предполагает последовательность нескольких действий — чек‑лист с ответственными по каждому пункту.

Чем больше обязательных полей и статусов, тем меньше вероятность, что сотрудники будут поддерживать систему в актуальном состоянии.

Как Scrum работает в РМС сегодня

Стендап должен синхронизировать сотрудников, а не превращаться в отчёт. Стендап в РМС со временем перестал быть механическим ответом на вопросы «что сделал», «что буду делать» и «что мешает».

Главная задача встречи — понять, движется ли команда к общей цели и где требуется помощь.

Если сотрудник просто перечисляет свои задачи, а коллеги ждут очереди выступить, синхронизации не происходит. Рабочий стендап должен выявлять зависимости: кому не хватает информации, где застряло согласование, какая задача блокирует остальные.

У стендапов РМС появилась и собственная особенность — короткие разминки.

Это может быть вопрос, мини‑игра, обсуждение события компании или повторение темы после обучения. Через такие активности команды узнают о книжном клубе, волонтёрских проектах, внутренних мероприятиях и работе других подразделений. Иногда разминка превращается в простой обмен новостями — например, кто‑то расскажет, как провёл выходные. Это помогает командам почувствовать себя ближе друг к другу.

Разминки помогают сотрудникам переключиться с индивидуальных задач на командную работу. Но они полезны только при одном условии: основная часть стендапа не должна из‑за них страдать.

Разминку стоит сократить или убрать, если она:

• занимает больше нескольких минут;
• требует долгой подготовки;
• проводится только потому, что «так принято»;
• отодвигает разговор о реальных проблемах.

Ретроспективы стали решать разные задачи. Изначально ретроспектива использовалась для разбора спринта: что получилось, что мешало и что команда изменит в следующем цикле.

Со временем в РМС появились дополнительные форматы.

Классическая ретроспектива. Команда разбирает работу за прошедший период и выбирает одно или несколько изменений.

Важно не превращать встречу в повторяющееся обсуждение одних и тех же проблем. Каждая ретроспектива должна завершаться проверяемым решением. Например:

• сократить число этапов согласования;
• изменить порядок передачи задачи;
• добавить критерии готовности;
• назначить одного ответственного за спорный участок процесса.

На следующей встрече команда проверяет, помогло ли изменение.

Ретроспектива для развития взаимодействия. На складе в Шахтах такие встречи проводили с сотрудниками входного контроля качества и склада. Участники разбирали рабочие ситуации и обсуждали, почему важно сразу сообщать о проблеме, а не надеяться, что её исправит кто‑то другой.

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

В этом случае ретроспектива помогает перевести корпоративную ценность «Строим честные и открытые отношения» из формулировки в конкретное рабочее поведение.

Ретроспектива для развития навыков. В продающих командах РМС проводили ретроспективы по самопрезентации. Сотрудники учились объяснять ценность своей работы, аргументировать решения и представлять продукт.

Формат использовали не как замену полноценному обучению, а как практическую тренировку на ситуациях, с которыми команда сталкивается каждый день.

Кросс‑командная ретроспектива. Если проблема находится на стыке подразделений, обсуждать её внутри одной команды бессмысленно.

Поэтому в РМС проводят совместные ретроспективы нескольких команд раз в квартал или по запросу команды. Они помогают разобрать задержки, несовпадение ожиданий и ситуации, когда решение одного отдела создаёт сложности для другого.

Их главный результат — не общее обсуждение, а договорённость: что меняется в совместном процессе, кто отвечает за изменение и когда участники проверят результат.

Но кросс‑командные ретро не обязательно связаны с проблемами на стыке подразделений. Например, одна из последних кросс‑командных ретроспектив была посвящена типологии DISC: участники из разных отделов разбирали типы личности и то, как учитывать их в совместной работе. Другая встреча была ориентирована на адаптацию новых сотрудников — в один из кварталов в компанию пришло около восьми новых людей, и ретроспектива помогла им быстрее включиться в командную работу.

В 2024 году результаты начали презентовать сами команды

До 2024 года квартальные итоги РМС обсуждали в основном руководители. Они собирались на два дня, анализировали показатели и определяли дальнейшие шаги.

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

В первом квартале 2024 года в РМС появились квартальные ревью. Теперь команды сами рассказывают, какие цели ставили, что выполнили, где ошиблись и над чем будут работать дальше.

Ревью проходят в первые две недели нового квартала. В них участвуют и те подразделения, которые не работают по Scrum в полном объёме.

РМС взяла принцип классического Scrum Review и расширила его до уровня всей компании. В результате квартальный отчёт перестал быть закрытой встречей руководителей.

Команды получили возможность говорить о собственной работе, а сотрудники — видеть, чем занимаются соседние подразделения и как их решения связаны между собой.

Публичная презентация также изменила качество отчётов. Перечислить выполненные задачи оказалось недостаточно. Команде нужно объяснить, что изменилось для бизнеса, клиента или внутреннего процесса.

Со временем РМС разработала единую структуру презентации. Она строится вокруг пяти вопросов:

1. Какую цель ставила команда?
2. Какой результат получила?
3. Что не получилось и почему?
4. Какие выводы сделала?
5. На чём сосредоточится в следующем квартале?

Такая структура не позволяет спрятать отсутствие результата за количеством выполненных задач.

Сегодня сооснователи компании Фёдор Сучков и Владимир Сурков — постоянные участники квартальных ревью команд, и сотрудники их присутствия ждут, а не терпят.

Это ощутимо отличается от ситуации, когда собственник появляется на встречах только для контроля результата. В РМС сооснователи включены в процесс на тех же условиях, что и остальные участники: слушают, что получилось и что не получилось, задают вопросы, дают обратную связь.

Где заканчивается классический Scrum и начинается подход РМС

Квартальные презентации, разминки и межкомандные встречи не входят в классическую методологию. В РМС они выросли из Scrum‑практик, но стали самостоятельными инструментами.

Разделять форматы важно, чтобы сотрудники понимали назначение каждой встречи:

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

Когда одна встреча пытается решить все задачи сразу, она становится длинной и бесполезной.

Скрам‑мастер — часть HR‑отдела. Ещё одна особенность подхода РМС — расположение роли Scrum‑мастера в организационной структуре. В компаниях, где Scrum‑мастер работает в единственном лице, он обычно подчиняется напрямую собственнику. В РМС основной Scrum‑мастер подчиняется HR и входит в состав HR‑отдела.

Что Scrum дал растущей компании

За несколько лет РМС прошла путь от двух пилотных команд до системы, которая связывает разные подразделения и уровни управления.

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

Из ретроспективы появилась традиция публичных благодарностей. Физические доски сменились виртуальными. Стендапы получили разминки. Ретроспективы начали использовать для развития сотрудников и решения межкомандных проблем. Квартальные результаты стали презентовать сами команды.

Но главным изменением стало не количество встреч.

По мере роста компании РМС создавала пространства, где сотрудники могли говорить о проблемах до того, как они становились системными, разбирать ошибки без поиска виноватых и предлагать изменения в собственных процессах.

Scrum стал не готовой моделью управления, а основой для формирования собственной системы командной работы.

Что из опыта РМС можно применить в вашей компании

Начинайте с небольшого пилота. Не переводите на Scrum всю компанию, пока не проверили метод на реальных процессах.

Разбирайте качество встреч. Сам факт проведения стендапа или ретроспективы ничего не говорит об их пользе.

Не передавайте ответственность без полномочий и правил. Самоорганизация требует чётких границ.

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

На ретроспективе выбирайте конкретное изменение. И обязательно проверяйте, сработало ли оно.

Не сохраняйте практику только потому, что она прописана в методологии. Инструмент должен решать рабочую задачу.

Пересматривайте систему по мере роста компании. Формат, удобный для пяти человек у физической доски, не подойдёт компании с несколькими подразделениями и распределёнными командами.

Дайте основателям место в процессе, а не только в отчётах. Присутствие первых лиц на ревью и стендапах — сильный сигнал того, что метод важен, а не просто модный инструмент.

Подумайте, где должен находиться Scrum‑мастер в стуктуре компании. Подчинение HR, а не напрямую собственнику, может помочь встроить в процессы не только эффективность, но и корпоративную культуру.

Scrum не стал для РМС системой, которую однажды внедрили и перестали менять. По мере роста компании менялись доски, встречи и зоны ответственности команд. Сохранялся главный принцип: каждый инструмент должен помогать видеть общий результат, раньше замечать проблемы и превращать опыт сотрудников в конкретные улучшения.