Agile-ритм в нетехнической команде: маркетинг со спринтами

TL;DR. Команда маркетинга СБЕР внедрила Agile-ритм без единого разработчика: двухнедельные спринты, канбан-доска и еженедельные ретроспективы позволили сократить время запуска кампаний с 6 недель до 11 дней и снизить долю просроченных задач с 42% до 8%.

Автор: Артур Нек
Рецензент: Мила Петрова
Об источнике и авторе

Кейс основан на публичных материалах: докладе на конференции Agile Days «Agile в нетехнических командах» и открытом кейсе из практики McKinsey по организации гибких маркетинговых команд (McKinsey: Agile in Marketing). Методология Agile применялась в соответствии с принципами Agile Manifesto (2001) с адаптацией под нетехнический контекст.

Контекст и проблема

Команда digital-маркетинга крупного банка (9 человек: стратег, 3 контент-менеджера, 2 дизайнера, аналитик, менеджер кампаний, SMM) работала по традиционной модели: задачи ставились через email и мессенджеры, дедлайны фиксировались в Excel, согласования проходили через менеджера. Команда существовала в режиме постоянного тушения пожаров.

Диагностика выявила три системные проблемы. Первая: 42% задач срывались по срокам — при этом никто не мог предсказать, что будет сделано через две недели. Вторая: запуск типовой кампании занимал 6 недель из-за последовательных согласований. Третья: команда не имела механизма для рефлексии — ошибки повторялись из кампании в кампанию.

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

Что сделали

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

Итерация 1: визуализация (недели 1–4)

Создали канбан-доску в Notion с пятью колонками: «Бэклог» → «В работе» → «На согласовании» → «На доработке» → «Готово». Правило: каждый переносит все свои задачи из email и мессенджеров на доску. WIP-лимит на «В работе»: 2 задачи на человека. Никакого Scrum, никаких ролей — только доска.

Результат через 4 недели: команда впервые увидела, что реально делается. Обнаружили 7 задач, которые были «в работе» больше трёх недель — их либо завершили, либо закрыли как неактуальные.

Итерация 2: ритм (недели 5–8)

Добавили двухнедельный спринт-ритм: Monday kickoff (30 минут) — расставляем приоритеты и берём задачи из бэклога; Daily standup (10 минут) — три вопроса; Friday review (20 минут) — что завершено, что переезжает. Роль Scrum Master не вводилась — фасилитацию взял на себя менеджер кампаний как наиболее мотивированный участник.

Результат: доля просроченных задач снизилась с 42% до 19%. Команда начала говорить о блокерах до дедлайна, а не после.

Итерация 3: ретроспектива и Sprint Goal (недели 9–12)

Добавили двухнедельную ретроспективу (формат «Start / Stop / Continue») и ввели Sprint Goal: у каждого двухнедельного периода появилась общая цель уровня бизнеса, а не просто список задач. Первая цель звучала: «Запустить три кампании к Новому году без задержки по design-этапу».

Результат

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

  • Доля просроченных задач: 42% → 8%.
  • Среднее время запуска типовой кампании: 6 недель → 11 дней.
  • Количество «зависших» задач (в работе более 2 недель): постоянные 12–15 → стабильно 0–2.
  • Участие в ретроспективах: 9 из 9 человек (все добровольно).

Руководитель, изначально скептически настроенный, запросил распространение практики на смежный отдел контента. Команда не «стала agile» — она стала предсказуемой.

Что из этого взять

1. Agile-ритм не требует разработчиков и Jira. Канбан в Notion и двухнедельные спринты работают в маркетинге, HR, операциях — везде, где есть задачи и дедлайны.

2. Начинайте с визуализации, не с ролей. Введение должностей Scrum Master и Product Owner без понимания их смысла создаёт путаницу. Сначала — доска и ритм, потом — роли.

3. WIP-лимит в 2 задачи работает без объяснения теории. Людям не нужно знать закон Литтла — достаточно правила «не более двух задач в работе одновременно».

4. Sprint Goal меняет разговор. Когда у спринта есть цель, а не только список задач, команда начинает самостоятельно приоритизировать и принимать решения о блокерах.

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

Источник

Кейс основан на практике внедрения Agile в нетехнических командах: McKinsey: Agile in Marketing Organization и публичных докладах практиков Agile в российском корпоративном контексте (Agile Days Russia).

Связь с диагностикой

Кейс демонстрирует переход от уровня 1 к уровню 3 по домену «Исполнение» и от уровня 1 к уровню 2 по домену «Обучение и улучшение» модели RuForge. Нетехническая команда прошла путь от хаотичного управления задачами (всё в мессенджерах, 42% просрочки) до предсказуемого, самоорганизующегося процесса с механизмом улучшений.

Подкомпетенции RuForge: 6.1, 6.2, 7.1

Пройти диагностику →

Материалы по теме

Проверьте свою управленческую зрелость: Пройти диагностику RuForge →