Zombie Scrum
Тема дорожной карты · Agile / Scrum / Kanban
Zombie Scrum (Verwijs/Schartau/Overeem, 2017) — это состояние команды, которая механически выполняет церемонии Scrum (planning, daily, review, retro), но не выпускает работающего ПО, не взаимодействует с пользователями и не демонстрирует непрерывного улучшения. Это состояние, когда тело команды продолжает двигаться, но жизнь в ней исчезает. Это явление часто возникает из-за того, что менеджмент измеряет только output (скорость выполнения задач), а не outcome (доставленную ценность).
Как это работает
Симптомы Zombie Scrum включают регулярные, но скучные церемонии Scrum, где решения не принимаются; отсутствие информации о том, что пользователи делают с продуктом; постоянную скорость выполнения задач (velocity), но отсутствие понимания влияния новых функций (impact); ретроспективы, которые не приводят к конкретным улучшениям; и общее согласие команды, что все «в порядке». Со временем, по мере того как участники понимают, что их голос не имеет значения, они начинают замолкают, что приводит к снижению вовлеченности. В конечном итоге команда превращается в сервисную очередь для запросов менеджмента, и ценность от Scrum исчезает.
Когда применять
Диагностировать Zombie Scrum можно, задавая команде три ключевых вопроса: (1) Когда последний раз команда обсуждала с пользователями реальные проблемы и возможности улучшения? (2) Какие конкретные изменения были внедрены после последней ретроспективы? (3) Как команда измеряет свою эффективность и ценность? Четвёртый вопрос — когда команда последний раз общалась с реальным пользователем? Ответы, такие как «никогда» или «месяцы назад», указывают на отсутствие петли обратной связи, которая придаёт Scrum смысл.
Типичные ошибки
(1) Добавление новых церемоний — это типичная ошибка, когда команда пытается решить проблему добавлением новых церемоний Scrum. Это усугубляет проблему, так как новые церемонии также могут лишиться смысла без обратной связи от пользователей. (2) Переобучение Scrum Master — проблема команды не в том, что Scrum Master не знает Scrum, а в том, что команда не понимает важности взаимодействия с пользователями и достижения конкретных результатов. Дополнительное обучение Scrum Master не решает проблему. Решение заключается в соединении команды с реальными пользователями, например, позволяя разработчикам просматривать реальные сессии пользователей или ротируя инженеров в службу поддержки пользователей на неделю. Это помогает команде понять, как их работа влияет на пользователей и как можно улучшить результаты.