Блог Scrum.ru

Антипаттерны Ежедневного скрама: 24+2 способа улучшить Scrum команду

Перевод оригинальной статьи Stefan Wolpers “Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team”
Автор перевода Толкачёва Валерия, Scrum Master (Telegram: @Val1eriya)
По моему опыту, Daily Scrum - это событие с самой высокой плотностью антипаттернов среди всех событий Scrum. Узнайте больше об антипаттернах Daily Scrum, которые угрожают успеху вашей Scrum команды - от превращения его в отчетную сессию до задачи отвечать на три вопроса.

Цель Daily Scrum

Цель Ежедневного скрама четко описана в Руководстве по Scrum - никаких догадок не требуется:
Цель Daily Scrum — инспекция прогресса в достижении Sprint Goal, адаптация Sprint Backlog по мере необходимости, корректировка запланированной предстоящей работы.

Daily Scrum — это 15-минутное событие для Developers, входящих в Scrum Team. Для снижения комплексности событие проводится в одно и то же время, в одном и том же месте, каждый рабочий день в ходе Sprint. Если Product Owner или Scrum Master активно работают над элементами из Sprint Backlog, то они участвуют в событии в качестве Developers.

Developers могут выбирать любую структуру и техники, которые сочтут нужными, при условии, что их Daily Scrum фокусируется на достижении Sprint Goal и создает план действий на следующий рабочий день. Это обеспечивает сфокусированность и улучшает самоуправление.

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

Developers разрешено корректировать свой план не только во время Daily Scrum. Они часто встречаются в течение дня для более подробного обсуждения возможностей адаптации и перепланирования оставшейся работы на Sprint.
Ежедневный скрам - это важное событие для инспекции и адаптации, проводимое Разработчиками и направляющее их в течение следующих 24 часов на пути к достижению Цели спринта. Таким образом, Ежедневный скрам - это самый короткий горизонт планирования в Scrum и, следовательно, очень эффективный способ направлять усилия Скрам команды.

Вопреки распространенному мнению, этот 15-минутный интервал не предназначен для решения всех проблем, возникающих в ходе Ежедневного скрама. Речь идет о создании прозрачности, что инициирует инспекцию. Если требуется внесение изменений в план или Бэклог спринта, разработчики вправе решать возникшие проблемы в любое время. Из моего опыта могу сказать, что большинство антипаттернов Ежедневного скрама происходят из-за непонимания этого ключевого принципа.

Антипаттерны Ежедневного скрама - от Дисфункциональных Скрам команд до организационных неудач/провалов

Обычно хорошей Скрам команде не требуется более 10–15 минут, чтобы проверить прогресс в достижении Цели спринта. Учитывая этот короткий период, интересно отметить, что Ежедневный скрам часто изобилует антипаттернами. Антипаттерны часто охватывают широкий спектр, начиная от поведения, обусловленного неэффективными Скрам командами, и заканчивая очевидными неудачами на организационном уровне.

Мой неприоритетный список пресловутых антипаттернов Ежедневного скрама выглядит следующим образом:

Антипаттерны Ежедневного скрама для Скрам команды

  • Потеря ориентира: Ежедневный скрам служит одной цели - ответить на простой вопрос: мы все еще движемся к достижению Цели спринта? Или нам необходимо адаптировать план или Бэклог спринта или и то, и другое? Иногда Разработчики не могут сразу ответить на этот вопрос. (В этом отношении визуализация прогресса к Цели спринта полезна. Удаление из Руководства по Scrum несколько лет назад обязательного поддержания Разработчиками графика сгорания работы (burndown chart) не означает, что такая визуализация бесполезна.)

  • Отчет о статусе: Ежедневный скрам - это встреча для проверки статусов, и Разработчики стоят в очереди, чтобы “отчитаться” о проделанной работе перед Скрам-мастером, Владельцем продукта или, возможно, даже стейкхолдером. (“Три ежедневных вопроса” часто служат шаблоном для этого анти-шаблона.)

  • Отсутствие рутины: Ежедневный скрам не проводится каждый день в одно и то же время и в одном и том же месте. (Хотя рутина может испортить любую Ретроспективу, она полезна в контексте Ежедневного скрама. Относитесь к этому, как к спонтанной тренировке: не заморачивайтесь слишком сильно на Ежедневном скраме, просто делайте это. Пропуск Ежедневного скрама может быть скользкой дорожкой: если вы пропустили один или два, почему бы не пропускать каждый второй?)

  • Неуважение I: Другие члены команды разговаривают, когда кто-то делится своим прогрессом. (Использование "токенов разговора" среди взрослых для предотвращения такого поведения не считается решением на мой взгляд.)

  • Неуважение II: Члены команды опаздывают на Ежедневный скрам или не приходят вообще. (Этот сбой представляет собой огромный риск для Разработчиков, поскольку они инспектируют и, вероятно, адаптируют свой план для достижения Цели спринта на основе неполной информации, что снижает вероятность достижения Цели спринта.)

  • Чрезмерная обратная связь: Члены команды сразу же критикуют друг друга, вызывая дискуссию, вместо того чтобы выносить свою критику за рамки Ежедневного скрама.

  • Переполненность: Ежедневный скрам неэффективен из-за большого количества активных участников. (Есть причина, по которой Руководство по Scrum рекомендует ограничить количество членов команды до десяти.)

Антипаттерны Ежедневного скрама для Разработчиков

  • Невежество: Разработчики не готовы к Ежедневному скраму. («Я что-то делал, но не могу вспомнить, что именно. Хотя это было важно».)

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

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

  • Монологи: Члены команды нарушают временной интервал, начиная монологи. (От 60 до 90 секунд на каждого члена команды должно быть более чем достаточно для эфира.)

  • Статлер и Уолдорф: Несколько членов команды комментируют каждый вопрос. (Обычно это не просто трата времени, но и проявление снисходительности и раздражения.)

  • Только номера задач: Обновления носят общий характер и практически не имеют значения для других пользователей. (“Вчера я работал над X-123. Сегодня я буду работать над X-129”).

  • Никаких препятствий: никто не сообщает о каких-либо препятствиях; никто не нуждается в помощи или поддержке со стороны своих товарищей по команде. (Поздравляю вас с вашей, казалось бы, хорошо отлаженной машиной! Однако, возможно, Разработчики не чувствуют себя в безопасности, поднимая проблемы?)

Антипаттерны Ежедневного скрама для Владельца Продукта

  • Поручения: Владелец продукта назначает задачи непосредственно членам команды. (Разработчики самостоятельно организуют свою работу: «Никто не указывает им, как превращать элементы Product Backlog в Increments ценности». Источник: Руководство по Scrum 2020.)

  • Дополнительная работа: Владелец продукта или даже другие стейкхолдеры пытаются внести новую работу в текущий Спринт во время Ежедневного скрама. (Такое поведение может быть приемлемым для высокоприоритетных ошибок, хотя Разработчики должны знать о них до начала Ежедневного скрама. В ином случае, составление Бэклога спринта лежит исключительно на плечах Разработчиков: они могут принимать новые задачи в ходе Спринта, но именно они принимают окончательное решение по этому вопросу.)

Антипаттерны Ежедневного скрама для Скрам-Мастера

  • Инквизитор Ежедневного скрама: Скрам-мастер следит за проведением Ежедневного скрама. (Задача Скрам-мастера заключается в том, чтобы убедиться, "что все события Scrum происходят, позитивны, продуктивны и не выходят за рамки ограничений по времени." Тем не менее, если ни один из Разработчиков не считает, что Ежедневный скрам является разумной инвестицией времени, Скрам-мастер не может просто компенсировать отсутствие внутренней мотивации, применяя Руководство по Scrum в качестве принудительного механизма. Он должен помочь создать мотивацию на стороне Разработчиков для того, чтобы элементарно запустить Ежедневный скрам. Принуждение к проведению Ежедневного скрама — это обычный артефакт тейлоризма там, где отсутствует доверие к способности Разработчиков к самоорганизации.)

  • Отсутствие поддержки Разработчиков, испытывающих трудности: Разработчик сталкивается с проблемами при выполнении задачи в течение нескольких последовательных дней, и никто не предлагает помощи. Более того, Скрам-мастер не обеспечивает необходимое обсуждение этого. (Часто это свидетельствует о том, что люди либо не доверяют друг другу, либо не проявляют заботу друг о друге. В качестве альтернативы можно предположить, что нагрузка на Разработчиков достигла непродуктивного уровня, поскольку они больше не могут поддерживать друг друга. Использование информации о возрасте задачи (‘work item age’) будет полезной практикой.)

  • Не препятствовать участию стейкхолдеров: Хотя участие в Ежедневном скраме ограничено членами Скрам команды, стейкхолдеры появляются без приглашения, и Скрам мастер не решает эту проблему. (Решение о том, как проводить Ежедневный скрам, является прерогативой Разработчиков. Если они решают исключить стейкхолдеров из участия в нем, это решение должно всеми уважаться. Если стейкхолдеры этого не соблюдают, Скрам мастер должен вмешаться.)

  • Несоблюдение временных интервалов: Разработчики регулярно увеличивают продолжительность Ежедневного скрама и выходят за пределы 15-минутного временного интервала. (Это прискорбно, поскольку увеличение временного интервала приводит к тому, что решение проблем и другие действия включаются в повседневную работу, тем самым отвлекая от ответа на важнейший вопрос: мы все еще на пути к достижению Цели спринта?)

Антипаттерны Ежедневного скрама для стейкхолдеров

  • Управление и контроль со стороны руководства: Линейные менеджеры посещают Ежедневный скрам для сбора “данных о производительности” отдельных членов команды. (Такое поведение противоречит самой цели самоуправляемых Скрам команд).

  • «Одно слово, пожалуйста»: линейные менеджеры ждут окончания Ежедневного скрама, а затем обращаются к отдельным Разработчикам за конкретными отчетами. (Хорошая попытка. Однако этот хак также является нежелательным поведением и отвлекает Разработчиков.)

  • Разговорчивые цыплята: “Цыплята” активно участвуют в Ежедневном скраме. (Предполагается, что стейкхолдеры должны слушать, но не отвлекать Разработчиков во время инспекции).

  • Общение с помощью языка тела: Формально стейкхолдеры хранят молчание. Однако они участвуют в Ежедневном скраме с помощью языка тела. (Опять же, предполагается, что стейкхолдеры должны слушать, но не отвлекать Разработчиков. Однако закатывание глаз и жесты, так же действенны, как и произнесенные слова. Более того, даже едва заметные формы языка тела представляют собой коммуникацию, поскольку человек не может “не общаться”. Кроме того, присутствие некоторых стейкхолдеров может естественным образом устрашать, что может оказаться разрушительным для общения между Разработчиков.)

Пища для размышлений

Есть некоторые вопросы, которые стоит рассмотреть в Скрам команде:

  • Синхронный и асинхронный Ежедневный скрам: Некоторым командам нравится проводить Ежедневный скрам в Slack, особенно тем командам, которые не расположены в одном офисе. Но, конечно, использование Slack само по себе не является нарушением шаблона; это прерогатива Разработчиков - проводить Ежедневный скрам любым способом, который соответствует его цели: проверить план на следующие 24 часа, чтобы достичь Цели спринта. Я даже работал со Скрам командой, которая работала в одном месте, сидя за большим столом, и которая использовала синхронную сессию Slack в качестве предпочтительного способа проведения Ежедневного скрама. Это сработало хорошо. Но как насчет асинхронного Ежедневного скрама в Slack?

  • Замена Ежедневного скрама: Как насчет идеи вообще отказаться от Ежедневного скрама, поскольку Разработчики активно используют более или менее автоматизированные системы обмена сообщениями в большинстве аспектов своей повседневной работы, в то время как с остальным они могут справиться во время других активностей, например, объединения в пары или моббинга? Полезно ли при таких обстоятельствах выделять 15 минут каждый день на Ежедневный скрам? Или это просто догматизм?

Антипаттерны Ежедневного скрама - Выводы

Учитывая важность Ежедневного скрама для успешного достижения Цели Спринта Скрам командой, неудивительно, что в нем наблюдается высокая плотность антипаттернов. К сожалению, кажется, что люди либо неосведомлены (или по крайней мере менее информированы) о его целях, или они вмешиваются в самоорганизацию Разработчиков намеренно или случайно. Так или иначе, это является ключевой ответственностью Скрам мастера - помочь всем участникам преодолеть типичные антипаттерны Ежедневного скрама

Какие антипаттерны Ежедневного скрама вы наблюдали? Пожалуйста, поделитесь ими с нами в комментариях.
Scrum