Мы все сидели на бесконечных митингах и думали: “Вот это точно можно выкинуть из календаря”. Поэтому вопрос “а обязательно ли нам все эти Scrum события” звучит честно. Кажется логично: уберем одно – выиграем время.
Но в Scrum есть одна неудобная правда:
единственная причина, по которой нельзя пропускать ни одно событие, в том, что каждое из них – часть единой петли инспекции и адаптации. Уберете кусок – перестанете учиться.
Scrum стоит на эмпиризме: сначала делаем ставку, потом смотрим на реальность, потом подстраиваемся. Это тот же Deming cycle Plan-Do-Study-Act, только в одежде Scrum.
- Sprint Planning – Plan: договорились, чего именно попробуем в этот спринт и зачем.
- Сам спринт и Daily Scrum – Do и часть Study: делаем работу и каждый день сверяемся, что реальность не уехала от плана.
- Sprint Review – Study: вместе со стейкхолдерами честно смотрим, что получилось и кому это вообще нужно.
- Sprint Retrospective – Act: меняем процесс, соглашения, взаимодействие, чтобы в следующем цикле быть чуть умнее.
Как только команда говорит “ретро нам не нужно” – она фактически говорит “мы не хотим осознанно менять свою систему”. “Дейли нам не нужен” часто значит “мы готовы узнавать о проблемах через неделю, а не через день”. “Ревью – лишнее шоу” – “нас не особо волнует, что думает пользователь”. Формально Scrum как будто остается, но цикл PDSA уже треснул.
Скептики возражают: “Но у нас все события превратились в формальность, какой вообще от них толк?” И здесь они правы частично. Если “дейли” – это круговой статус для менеджера, а “ретро” – список пожеланий в никуда, то такое событие действительно можно выкинуть. Но проблема не в самом событии, а в том, что команда перестала использовать его для инспекции и адаптации. Вы не петлю вырезали – вы провод перегрызли.
Настоящая цена пропуска проявляется не в календаре, а в последствиях.
- Без внятного Sprint Planning команда “занимается задачами”, но не продвигает Product Goal.
- Без Daily Scrum мелкие блокеры растягиваются в многочасовые простои.
- Без Sprint Review продукт тихо уползает от потребностей пользователей.
- Без Retrospective мелкие шероховатости превращаются в хроническую боль.
Можно сколько угодно спорить о длительности, формате и частоте событий. Но как только вы начинаете выбрасывать куски петли инспекция-адаптация, вы отходите от Scrum в сторону “мы просто работаем по спринтам”. Внешне все так же, внутри – обычный проектный конвейер с красивыми названиями митингов.
Поэтому честный вопрос для любой команды звучит не “какое событие нам можно пропустить”, а “где именно мы сейчас перестали учиться”. Если вы оставите все четыре события, но вернете им смысл как точкам наблюдения и изменения курса, вы будете экономить не минуты в календаре, а недели на переделках и спасении проваленных инициатив.
Scrum события не для красоты и не для галочки. Это ваш единственный системный способ не застрять в иллюзиях.
Присоединяйся к общению с единомышленниками https://t.me/kanbanclub
“Какое Scrum событие в вашей реальности чаще всего превращается в бессмысленную формальность?”
Варианты ответов:
- Sprint Planning – собираемся, но реально ничего не выбираем и не режем
- Daily Scrum – превращается в статус-отчет “что делал вчера”
- Sprint Review – скучное демо без живого диалога со стейкхолдерами
- Sprint Retrospective – говорим “надо улучшить коммуникацию” и расходится
- Честно: у нас уже давно никакого Scrum нет, только спринты