Антипаттерны Scrum: карго-культ, зомби-скрам, мини-водопад

Есть болезненный факт, о котором редко говорят на тренингах: Scrum сам по себе не делает команду лучше. Он делает проблемы видимыми. Двухнедельный таймбокс не даёт спрятать «мы почти закончили» на полгода. Требование поставлять работающий инкремент вскрывает, что тестирование ручное и занимает неделю. Ретроспектива каждые две недели не даёт забыть, что процесс кривой.

А дальше происходит развилка. Либо организация начинает решать вскрытые проблемы — и тогда становится лучше. Либо она находит способ сделать проблемы снова невидимыми, сохранив внешнюю форму Scrum. Второй путь дешевле, привычнее и почти всегда выбирается по умолчанию. Результат этого выбора и называется антипаттернами Scrum.

Эта статья — каталог таких способов и, что важнее, метод их разбора. Мы не будем заучивать список «делай так, не делай эдак». Для каждого антипаттерна мы разберём: какая настоящая боль его породила, какую задачу он вроде бы решает, что ломается на самом деле — и что делает Scrum-мастер вместо того, чтобы читать команде Scrum Guide вслух.

Про то, как устроены сами элементы Scrum, — в статьях События Scrum, Артефакты и обязательства и Три ответственности. Здесь мы смотрим на то, во что они превращаются под давлением реальной организации.

Что такое антипаттерн и чем он опасен

Термин пришёл из книги «AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis» (Brown, Malveau, McCormick, Mowbray, 1998). Определение оттуда:

Антипаттерн — это часто встречающееся решение проблемы, которое порождает отчётливо негативные последствия.

Три слова здесь несут всю нагрузку.

«Часто встречающееся» — это не чья-то личная глупость. Если одно и то же поведение независимо возникает в сотнях компаний, значит, его порождает система, а не люди. Отсюда следует главное правило Scrum-мастера: антипаттерн нельзя вылечить, обвинив человека.

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

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

Так делать не стоит. Реагировать на симптом регламентом. «Дейли затягивается — ставим таймер и запрещаем садиться» снимет длительность на два спринта, после чего доклад вернётся, просто быстрее и бессодержательнее. Симптом — это точка входа в диагностику, а не объект лечения.

Диагностическая рамка: три вопроса эмпиризма

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

Эта рамка защищает и от обратной ошибки — «полиции Scrum». Если команда прекрасно поставляет ценность, честно инспектирует и меняется, но проводит дейли не в 10:00, а плавающим временем, — это не антипаттерн. Отклонение от формы становится проблемой только тогда, когда ломает один из трёх вопросов.

Карго-культ Scrum: форма без функции

Откуда термин

Ричард Фейнман в речи перед выпускниками Caltech в 1974 году описал жителей островов Тихого океана, которые после войны построили деревянные подобия взлётных полос, наушников из кокоса и антенн из бамбука — и ждали, что самолёты с грузом вернутся. Всё сделано похоже. Не хватает единственного: понимания, почему самолёты прилетали на самом деле.

Карго-культ Scrum — ровно это. Все события проводятся, все артефакты заведены, доска настроена, стикеры цветные. Но ни одно действие не связано с причиной, по которой оно существует.

Как выглядит

Что ломается

Карго-культ не нейтрален — он хуже, чем отсутствие Scrum. Причины две.

Во-первых, он расходует бюджет доверия. Команда тратит примерно 8–10% времени спринта на события. Если события ничего не дают, через полгода в организации формируется устойчивое убеждение «Scrum не работает» — и следующая попытка изменений встретит сопротивление, которое вы не заслужили.

Во-вторых, он создаёт ложную прозрачность. Есть доска, есть burndown, есть статусы — руководство уверено, что видит реальность. На самом деле оно видит аккуратно оформленную неправду. Это опаснее полного отсутствия информации: при отсутствии данных менеджер осторожен, при ложных данных — уверен.

Что делает Scrum-мастер

Так делают на практике. Не начинайте с «вы делаете Scrum неправильно». Начинайте с вопроса о назначении: «Что мы хотим получить от дейли? Если бы завтра его отменили — что бы мы потеряли?» Часто команда отвечает «ничего» — и это лучшая точка входа. Дальше проведите эксперимент: два спринта дейли идёт вокруг цели спринта и доски, а не по кругу людей, и на ретро сравниваем.

Приём, который работает почти всегда: временно отменить событие. Если ретроспектива — театр, договоритесь пропустить её один раз и посмотреть, что случится. Ничего не случится — и это диагноз, который команда поставит себе сама, а не вы ей. Формально Scrum Guide требует все события, поэтому это инструмент для крайних случаев и обсуждается с командой открыто как эксперимент, а не вводится тайком.

Зомби-скрам: пульса нет

Термин ввели Кристиан Вервейс, Йоханнес Шартау и Барри Оверем — сначала как сатирический проект, затем как книгу «Zombie Scrum Survival Guide» (Addison-Wesley, 2020). Определение авторов: зомби-скрам выглядит как Scrum на первый взгляд, но у него нет сердцебиения.

Отличие от карго-культа тонкое и полезное. Карго-культ — про непонимание: люди копируют форму, потому что не знают, зачем. Зомби-скрам — про безжизненность: люди всё понимают, но система вокруг не даёт ничему происходить. Команда знает, что надо говорить со стейкхолдерами, но их не пускают. Знает, что надо релизить чаще, но релизное окно раз в квартал утверждает комитет.

Авторы выделяют четыре области, в которых меряется пульс.

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

# Экспресс-диагностика зомби-скрама: отвечать только фактами
ценность_для_стейкхолдеров:
  - когда_команда_последний_раз_говорила_с_пользователем: "дата, а не «регулярно»"
  - сколько_внешних_людей_было_на_последнем_обзоре: 0
  - можем_назвать_метрику_которую_изменил_прошлый_спринт: false

скорость_поставки:
  - время_от_«готово_в_коде»_до_«у_пользователя»: "9 недель"
  - можем_ли_релизнуть_сегодня_если_понадобится: false
  - доля_ручного_регрессионного_тестирования: "80%"

непрерывное_улучшение:
  - сколько_действий_из_прошлого_ретро_завершено: 0
  - повторяются_ли_одни_и_те_же_темы_на_ретро: true

самоуправление:
  - кто_решает_кто_какую_задачу_берёт: "тимлид"
  - может_ли_команда_сказать_«в_этот_спринт_не_влезет»: false

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

Так делать не стоит. Лечить зомби-скрам улучшением встреч. Если команда не может релизить чаще квартала из-за релизного комитета, никакая идеальная ретроспектива этого не изменит. Scrum-мастер, который третий год улучшает формат дейли в организации, где решения принимает комитет, занимается самоуспокоением.

Мини-водопад: спринт как маленький проект

Что это

Самый распространённый и самый живучий антипаттерн. Внешне — Scrum: спринты, планирование, дейли. Внутри спринта — последовательные фазы: аналитика → разработка → тестирование → приёмка. Каждая фаза передаёт результат следующей.

Иногда фазы разъезжаются даже по разным спринтам: в спринте N аналитики пишут требования для спринта N+1, разработчики делают то, что подготовили в N−1, тестировщики проверяют сделанное в N−1. Такая конструкция называется конвейерным Scrum (staggered sprints) и в Scrum Guide не существует ни в каком виде.

Признаки, по которым распознаётся

• Тестирование — отдельный этап в конце спринта. Последние два дня «тестируем», первые дни тестировщики свободны.
• Горизонтальная нарезка задач. В спринте есть задачи «сделать API», «сделать фронтенд», «написать миграцию» — и ни одна из них по отдельности не даёт работающей функциональности.
• Инкремент готов только в последний день. Всё зелёное 25 января, потому что до 25 января ничего не было закончено целиком.
• Регулярные «хвосты». Каждый спринт 20–30% работы переносится, при этом команда искренне работала.
• Роли внутри команды жёсткие. «Это не моя задача, я бэкендер».
• Спринт стабилизации (hardening sprint) перед релизом — прямое следствие: качество не встроено, значит его надо «догнать» отдельной фазой.

Что ломается

Мини-водопад убивает главное свойство спринта — возможность узнать что-то раньше конца. Если результат появляется только на четырнадцатый день, спринт даёт ровно одну точку обратной связи вместо непрерывного потока. Формально итерация есть, эмпиризма нет.

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

Третье — невозможность торговаться скоупом. Scrum Guide прямо описывает механизм: при угрозе цели спринта разработчики договариваются с Product Owner об объёме. Но если ничего не готово целиком, выбрасывать нечего — все задачи в состоянии «наполовину».

Как чинить

Лечение мини-водопада почти всегда техническое и структурное, а не «процессное»:

1. Вертикальные срезы вместо горизонтальных. Задача формулируется как тонкий сквозной кусок пользовательской ценности, проходящий все слои. Подробно эта техника разобрана в Работа с бэклогом.
2. DoD, включающий тестирование и интеграцию. Пока «готово» означает «код написан», фаза тестирования неизбежна.
3. Кросс-функциональность внутри команды. Не «у каждого все навыки», а «внутри команды есть все навыки, чтобы довести срез до Done без внешних передач».
4. Ограничение незавершённой работы (WIP). Классический приём: команда договаривается, что одновременно в работе не более N элементов, и второй элемент нельзя начать, пока первый не доведён. Это заимствование из Kanban — разобрано в треке project-management.
5. Автоматизация регрессионного тестирования. Без неё пункты 1–4 упрутся в физику. Практики CI/CD разбираются в треке devops.

Так написано в Scrum Guide. Ни «спринта 0», ни «спринта стабилизации», ни «релизного спринта» в Scrum Guide нет. Спринт — контейнер фиксированной длины, внутри которого создаётся пригодный к использованию инкремент. Спринт, в котором не создаётся инкремент, — это не спринт Scrum, как бы его ни называли. На экзамене PSM I любой вариант ответа со словом hardening/Sprint 0 почти наверняка неверный.

Flaccid Scrum: Scrum без инженерных практик

Отдельно стоит назвать паттерн, который Мартин Фаулер описал в заметке FlaccidScrum. Сюжет типовой:

1. Команда внедряет Scrum и в первые месяцы ускоряется — фокус, приоритеты, меньше переключений.
2. Инженерные практики при этом не меняются: тестов мало, рефакторинга нет, архитектура ухудшается под давлением двухнедельных обещаний.
3. Кодовая база гниёт. Каждое новое изменение дороже предыдущего.
4. Через год velocity падает ниже стартовой, и организация делает вывод: «Scrum не работает».

Диагноз Фаулера: Scrum не содержит инженерных практик и не собирается их содержать — он «process framework», а не набор технических дисциплин. Это верно и по Scrum Guide, но означает не «практики не нужны», а «их придётся принести отдельно» — из XP (TDD, парное программирование, непрерывная интеграция, простой дизайн, коллективное владение кодом).

Что делает Scrum-мастер. Не учит разработчиков программировать — это не его роль. Но он делает связь между качеством и результатом видимой: показывает, сколько времени спринта уходит на баги прошлых спринтов, помогает выразить технический долг через DoD, доносит до Product Owner, что «быстрее сейчас» и «быстрее через полгода» — конфликтующие оптимизации. Экономика этого решения хорошо разобрана в заметке Фаулера Technical Debt.

Dark Scrum: фреймворк как инструмент давления

Рон Джеффрис, один из авторов Agile-манифеста, ввёл термин Dark Scrum для ситуации, когда механика Scrum используется против команды.

Как это выглядит:

• Velocity превращается в норму выработки. «В прошлом спринте 40 очков, в этом ждём 45». Дальше команда начинает инфлировать оценки — это единственная рациональная реакция. Механика этого искажения детально разобрана в Эмпиризм и метрики.
• Спринт становится обещанием, а не прогнозом. «Вы взяли на себя обязательство» — при том что Scrum Guide 2020 специально убрал слово «commitment» применительно к объёму работы, оставив его для целей.
• Дейли — ежедневный отчёт о выполнении. Не встреча команды для себя, а инструмент контроля.
• Ретроспектива — поиск виноватого. После двух таких ретро люди перестают называть проблемы.
• Оценки становятся дедлайнами. «Вы сказали 5 дней» — при том что 5 было медианой распределения.

Ключевая мысль Джеффриса: в Dark Scrum разработчики оказываются в худшем положении, чем до Scrum, — прозрачности стало больше, а защиты нет. Именно поэтому Scrum-мастер, отвечающий по Scrum Guide за эффективность и за устранение препятствий, не может быть нейтральным администратором процесса. Работа с этим — в Коучинг команды, конфликты и сопротивление.

Каталог частных антипаттернов по элементам

События

Артефакты

Ответственности

Организация вокруг команды

• Scrum как ребрендинг. Проектные менеджеры переименованы в Scrum-мастеров, аналитики — в Product Owner, всё остальное осталось. Диагноз простой: изменились ли права принятия решений? Если нет — сменились только таблички.
• Фабрика фич (feature factory, John Cutler). Команда меряется числом выпущенных фич, а не изменением поведения пользователей. Тема детально раскрыта в треке product-management.
• Матричное подчинение. Функциональный руководитель ставит цели, Scrum-команда — другие. Приоритеты конфликтуют каждый спринт.
• Аджайл-трансформация как проект с дедлайном. «К декабрю все команды должны перейти на Scrum» — изменение, навязанное в водопадной логике, воспроизводит водопад на новом уровне.
• Постоянные переброски людей между командами. Стабильность состава — предусловие для того, чтобы у команды вообще появилась своя динамика и предсказуемость.

Разбор сценариев: что делает Scrum-мастер

Сценарий 1. «Хвосты» каждый спринт

Команда четвёртый спринт подряд переносит 30% работы. На ретро вывод один и тот же: «взяли слишком много, в следующий раз возьмём меньше». Берут меньше — переносят те же 30%.

Разбор. Одинаковая доля переноса при разном объёме — сигнал, что дело не в объёме, а в структуре работы. Скорее всего, это мини-водопад: всё заканчивается одновременно в конце.

Что делает Scrum-мастер. Не спорит про оценки. Приносит данные: строит для последних спринтов картину, в какой день какой элемент перешёл в Done. Если Done появляется только на 13–14 день, картинка говорит сама за себя. Дальше — эксперимент на один спринт: разбить два верхних элемента на вертикальные срезы и ввести правило «не начинаем третий элемент, пока первый не Done». Замерить на ретро.

Сценарий 2. Руководитель требует отчёт по каждому разработчику

Директор по разработке просит Scrum-мастера присылать еженедельно, кто сколько задач закрыл, «чтобы понимать загрузку».

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

Что делает Scrum-мастер. Выясняет решение, которое руководитель принимает на основе этого отчёта. Затем предлагает данные, которые отвечают на его вопрос лучше и не разрушают команду: прогноз по Product Goal, время поставки от идеи до пользователя, доля времени на незапланированную работу. И приглашает на Sprint Review — это встроенный в Scrum канал прозрачности для стейкхолдеров. Метрики, которые для этого годятся, — в Эмпиризм и метрики.

Сценарий 3. Ретроспектива, где все молчат

Третье ретро подряд: «всё нормально», через десять минут расходятся. Проблемы при этом очевидно есть — они всплывают в курилке.

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

Что делает Scrum-мастер. Сначала проверяет состав: если на ретро сидит функциональный руководитель, дальше можно не искать. Затем меняет формат так, чтобы снизить цену высказывания: сбор данных письменно и анонимно до встречи, работа с фактами («когда именно это случилось»), а не с оценками людей. И главное — гарантирует, что из ретро выйдет ровно одно действие, которое будет сделано. Одна выполненная договорённость восстанавливает доверие быстрее, чем десять обсуждённых. Техники — в Фасилитация.

Как работать с антипаттернами: что не работает и что работает

Что не работает:

• Цитировать Scrum Guide как аргумент. Правота не меняет поведение. Человек, которому доказали, что он нарушает правила, защищается, а не меняется.
• Чинить всё сразу. У команды с зомби-скрамом найдётся двадцать антипаттернов. Атака по всем фронтам даёт нулевой результат и репутацию зануды.
• Обходить проблему технически. Заменить Jira, ввести новый шаблон, добавить колонку. Инструмент никогда не был причиной.
• Жаловаться наверх без предложения. Эскалация без сформулированного решения превращает Scrum-мастера в источник плохих новостей.

Что работает:

• Начинать с самого дорогого. Один антипаттерн, который стоит больше всего, — и вся энергия туда. Обычно это либо отсутствие цели спринта, либо DoD, не включающий качество.
• Делать боль видимой, а не рассказывать о ней. Диаграмма «в какой день элементы становятся Done», счётчик времени от коммита до прода, сумма часов на баги прошлых спринтов. Данные меняют разговор с «кто прав» на «что делаем».
• Формулировать всё как эксперимент с гипотезой и сроком. «Давайте два спринта попробуем X, гипотеза — уменьшится Y, на ретро смотрим и откатываем, если нет». Эксперимент отменяем, а значит не страшен — сопротивление падает в разы.
• Спрашивать, а не утверждать. «Что мешает нам релизить чаще?» получает лучшие ответы, чем «нам надо релизить чаще».
• Признавать ограничения честно. Если причина за пределами влияния команды, скажите это прямо и работайте с ней на своём уровне, а не имитируйте улучшения внутри.

Так делают на практике. Полезное правило приоритизации: сначала антипаттерны прозрачности, потом инспекции, потом адаптации. Чинить адаптацию при непрозрачных данных бессмысленно — команда будет адаптироваться к выдумке. Порядок столпов эмпиризма — это ещё и порядок лечения.

Вопросы в формате PSM I с разбором

1. Команда завершает разработку к концу спринта, но тестирование переносится на следующий спринт. Что должен сделать Scrum-мастер в первую очередь?

A. Предложить добавить в конце каждого релизного цикла спринт стабилизации B. Помочь команде сделать прозрачным, что незавершённая работа не является инкрементом, и работать с Definition of Done C. Попросить Product Owner планировать меньше работы D. Организовать отдельную команду тестирования

Верно: B. Корень проблемы — «готово» означает не то, что означает в Scrum. Вариант A институционализирует антипаттерн. Вариант C лечит симптом: доля переноса останется той же. Вариант D усугубляет, добавляя внешнюю передачу и разрушая кросс-функциональность.

2. Что из перечисленного соответствует Scrum Guide?

A. Sprint 0 нужен для подготовки архитектуры и инфраструктуры B. Спринт стабилизации проводится перед крупным релизом C. Новый спринт начинается сразу после завершения предыдущего D. Между спринтами допустим перерыв для подготовки следующего планирования

Верно: C. Scrum Guide: «Новый спринт начинается сразу после завершения предыдущего». Ни Sprint 0, ни hardening sprint, ни паузы между спринтами в Scrum не существуют. Подготовительная и инфраструктурная работа делается внутри обычных спринтов.

3. Менеджер просит Scrum-мастера повышать velocity команды на 10% в квартал. Как поступить Scrum-мастеру?

A. Согласиться и мотивировать команду брать больше очков B. Отказаться, поскольку velocity — метрика команды и не является целью; выяснить, какую бизнес-задачу менеджер решает, и предложить показатели ценности и времени поставки C. Объяснить, что velocity вообще нельзя измерять D. Сообщить менеджеру, что вмешательство в работу команды запрещено Scrum Guide

Верно: B. Velocity — вспомогательная практика прогнозирования, а не показатель эффективности; целевая velocity немедленно инфлирует оценки (закон Гудхарта). Вариант A — прямая дорога в Dark Scrum. Варианты C и D формально неверны и разрушают отношения со стейкхолдером вместо решения его задачи.

4. Команда решила отменить ретроспективу, потому что «процесс отлажен и обсуждать нечего». Что делает Scrum-мастер?

A. Соглашается — самоуправляемая команда вправе решать B. Оставляет ретроспективу, но сокращает до 15 минут C. Объясняет назначение события и помогает команде найти формат, дающий пользу; ретроспектива остаётся D. Эскалирует руководству

Верно: C. События Scrum обязательны — их отмена уничтожает возможность инспекции и адаптации, а самоуправление касается того, как делать работу, а не отмены элементов фреймворка. Вариант B чинит длительность вместо содержания. Вариант D разрушает доверие и не решает задачу.

5. В организации на одного Scrum-мастера приходится пять команд, он занят только проведением событий. Каково главное последствие?

A. Никакого — проведение событий и есть работа Scrum-мастера B. Scrum-мастер перегорит C. Роль сводится к фасилитации встреч, работа с организационными препятствиями и развитием команд не выполняется — почти гарантированный карго-культ D. Команды станут более самостоятельными

Верно: C. По Scrum Guide Scrum-мастер отвечает за эффективность Scrum-команды и служит организации: помогает внедрять эмпирический подход, снимает препятствия, работает со стейкхолдерами. При «20% на команду» остаётся только внешняя форма.

6. Product Owner передаёт команде решения, принятые комитетом заказчиков, и не может изменить приоритет самостоятельно. Что здесь нарушено?

A. Ничего, если комитет решает быстро B. Product Owner — один человек, и его решения должны уважаться; иначе теряется скорость принятия решений и подотчётность за ценность C. Комитет должен присутствовать на всех событиях Scrum D. Scrum-мастер обязан заменить Product Owner

Верно: B. Scrum Guide: Product Owner — один человек, а не комитет; желающие изменить бэклог могут делать это, убеждая Product Owner. Прокси-PO без полномочий превращает бэклог в очередь заявок и останавливает спринт на каждом уточнении.

7. На Sprint Review приходят только члены Scrum-команды. Что теряется в первую очередь?

A. Ничего, обзор — внутреннее событие команды B. Возможность продемонстрировать руководству выполнение плана C. Инспекция инкремента ключевыми стейкхолдерами и совместная адаптация Product Backlog D. Возможность утвердить релиз

Верно: C. Sprint Review — рабочая сессия, на которой Scrum-команда и стейкхолдеры обсуждают результат и то, что изменилось в среде, и адаптируют бэклог. Без стейкхолдеров петля обратной связи разорвана. Вариант D — отдельный антипаттерн: обзор не является шлюзом релиза, инкремент может быть выпущен в любой момент спринта.

Типичные ошибки самого Scrum-мастера

1. Считать себя носителем истины. Позиция «я знаю, как правильно» превращает любое обсуждение в спор о власти. Работающая позиция: «вот что я наблюдаю, вот данные, что мы с этим сделаем?»
2. Пытаться убрать симптом, не поняв боль. Отменить спринт стабилизации, не решив вопрос качества, — значит выпустить в прод то, что раньше ловилось. Сначала альтернатива, потом отмена.
3. Путать «не по Scrum Guide» с «плохо». Story points, Definition of Ready, доска задач — не в Scrum Guide, но и не запрещены. Критерий — эмпиризм, а не буква.
4. Молча копить наблюдения. Список из тридцати антипаттернов, который Scrum-мастер держит в голове полгода, а потом вываливает на ретро, гарантированно вызовет защиту, а не изменения.
5. Пытаться починить то, что вне влияния, и игнорировать то, что внутри. Полезно явно разделить: что команда может изменить сама на этой неделе, что требует переговоров, что — решение руководства. Первое — делать сразу.
6. Забывать про собственную ответственность за прозрачность. Если Scrum-мастер сглаживает статус для руководства «чтобы не давили на команду», он собственноручно строит карго-культ.

Мини-итог

• Антипаттерн — часто встречающееся решение настоящей боли, дающее отложенный негативный эффект. Он не про глупость людей, а про систему. Не поняв решаемую им боль, убрать его нельзя.
• Карго-культ — форма без функции: события и артефакты есть, назначения нет. Опаснее отсутствия Scrum, потому что расходует доверие и создаёт ложную прозрачность.
• Зомби-скрам — всё формально есть, но пульса нет: не создаём ценность, не поставляем быстро, не улучшаемся, не самоуправляемся. Лечится не улучшением встреч, а работой с организационными ограничениями.
• Мини-водопад — фазы внутри спринта. Убивает раннюю обратную связь и возможность договариваться об объёме. Лечится вертикальными срезами, сильным DoD, кросс-функциональностью, ограничением WIP и автоматизацией тестов.
• Flaccid Scrum — Scrum без инженерных практик: быстрый старт, деградация через год. Практики приходится приносить из XP отдельно.
• Dark Scrum — механика фреймворка используется для давления: velocity как норма, дейли как отчёт, оценки как дедлайны.
• Sprint 0, hardening sprint, «почти Done», PO-комитет, прокси-PO, SM-администратор — не существуют в Scrum Guide ни в каком виде; на экзамене такие варианты почти всегда неверные.
• Метод работы: симптом → гипотеза о боли → сделать боль измеримой → эксперимент на 1–2 спринта → инспекция на ретро → закрепление. Проповедь Scrum Guide не входит в метод.
• Порядок лечения совпадает с порядком столпов эмпиризма: прозрачность → инспекция → адаптация.

Источники

• The Scrum Guide 2020 — первоисточник; любой антипаттерн проверяется против него, а не против пересказов.
• Scrum.org: What is ScrumBut? — классическая формула «мы используем Scrum, но… поэтому…» и почему остаток обычно и есть проблема.
• Christiaan Verwijs, Johannes Schartau, Barry Overeem. Zombie Scrum Survival Guide и сайт zombiescrum.org — четыре области диагностики и набор экспериментов.
• Richard Feynman. Cargo Cult Science — исходная метафора, стоит прочесть целиком.
• Martin Fowler. FlaccidScrum и TechnicalDebt — про Scrum без инженерных практик и экономику долга.
• Ron Jeffries. Dark Scrum — как фреймворк оборачивается против разработчиков.
• Dave West, Forrester Research. Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today (2011) — отчёт, который дал имя гибриду; автор впоследствии возглавил Scrum.org.
• Stefan Wolpers. Scrum Anti-Patterns Guide — большой практический каталог по событиям, артефактам и ролям.
• Brown, Malveau, McCormick, Mowbray. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998) — источник самого понятия.
• John Cutler. 12 Signs You’re Working in a Feature Factory — организационный антипаттерн вокруг Scrum-команды.

Что дальше

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

Масштабирование Scrum: Nexus, LeSS, SAFe — что нужно знать для экзамена