Хорошо для начала квартала или при смене направления
Визуально вовлекает и снижает защитные реакции
Работа с "тихими" участниками
Онлайн ретро и extroverted members подавляют quiet voices:
Silent writing first: все пишут стикеры параллельно (2–3 мин), потом обсуждают
Anonymous tools (Miro, FunRetro): снижает social pressure
Rotating facilitator: разные люди ведут ретро — все чувствуют ответственность
Explicit invite: "Алексей, ты сегодня молчишь — что думаешь о X?"
Action items ретроспективы
Главная проблема ретроспектив — отсутствие follow-through:
Максимум 3 action items за спринт (лучше 1–2)
Каждый item: owner + конкретное action + deadline
Первые 5 минут следующей ретро: проверь статус предыдущих items
Если одна и та же проблема появляется 3 ретро подряд — это системная проблема, реши её вне ретро
Кейс: Команда которая ненавидела ретроспективы
Контекст: Backend команда из 6 человек. Scrum мастер (он же PM) проводил ретро каждые 2 недели. Формат: "что хорошо, что плохо". Через 3 месяца участие упало: люди молчат или говорят "всё нормально".
Что пошло не так:
SM не фасилитировал — он записывал пункты и иногда оправдывался за "плохое"
Action items не выполнялись — через 2 недели то же самое
Формат не менялся 3 месяца
Критика превращалась в личные нападки ("Вася медленно делает задачи")
Что помогло:
Новый SM (ротация на 1 квартал) — разрыв паттерна
Переход на anonymous Miro стикеры — сразу появились честные комментарии
Правило: максимум 2 action items, оба с owner
Начало каждого ретро: 2 мин на статус предыдущих items
Mad/Sad/Glad формат — вышла наружу настоящая проблема (перегрузка, не технические процессы)
Результат: через 2 месяца участие восстановилось, команда начала доверять процессу.
⚠️ Типичные ошибки
Ошибка
Почему это плохо
Как исправить
SM назначает задачи разработчикам
Разрушает самоорганизацию, команда перестаёт думать самостоятельно
SM фасилитирует, команда сама берёт задачи с доски
Definition of Done меняется под каждую задачу
Нет единого стандарта качества, возникает «почти готово»
Один DoD для всех задач команды, меняется только командой целиком
Velocity используют как KPI разработчика
Команда накручивает цифры, растёт технический долг
Velocity — исключительно инструмент прогнозирования спринтов
PO добавляет задачи в Sprint Backlog в середине спринта
Срыв Sprint Goal, команда теряет фокус
Изменения — только в Product Backlog, войдут в следующий спринт
Ретроспектива без конкретных действий
Ничего не меняется, команда теряет веру в процесс
Максимум 3 действия с конкретным ответственным и дедлайном
Daily Scrum превращается в отчёт менеджеру
Люди говорят то, что хотят услышать, а не правду
Daily ведёт команда для себя, SM не задаёт вопросы каждому
Практические упражнения
Упражнение 1: Анализ текущей практики
Оцените вашу текущую реализацию Scrum по критериям:
Какие роли существуют и как они выполняются?
Как организованы церемонии?
Как управляется Product Backlog?
Как определяется Definition of Done?
Упражнение 2: План улучшения
Выберите одну область и разработайте план улучшения:
Какую область выберете?
Какие проблемы видите?
Какие действия предпримете?
Как будете измерять успех?
Заключение
Scrum — это мощный фреймворк для управления сложными проектами, но его успех зависит от правильного применения и адаптации под контекст.
Ключевые выводы:
Фокус на ценности для клиента, а не на процессах
Самоорганизация команды — основа успеха
Definition of Done обеспечивает качество
Velocity для прогнозирования, а не для оценки
Успех измеряется бизнес-результатами
🎯 Следующий шаг: Проведите аудит вашей команды и начните с одного улучшения на следующем спринте.
Время освоения: 40 минут
Уровень: Средний
Для кого: Scrum Masters, Team Leads, Product Owners, разработчики, менеджеры проектов