Паттерны устранения препятствий для Scrum команд
Изучите практические паттерны выявления и устранения препятствий в Scrum. Узнайте, как расширить возможности самоуправляемых команд и ликвидировать первопричины проблем на уровне всей организации.
Большинство инженерных команд мирятся с трением, от которого следовало бы избавиться. В Scrum препятствием считается все, что замедляет или останавливает движение Scrum Команды к Sprint Goal. Это не просто сбой сервиса или внезапная болезнь разработчика. Препятствие представляет собой любое организационное трение, технический долг или процедурный барьер, ограничивающий поставку. То, как команда справляется с подобными трудностями, показывает, является ли она по-настоящему самоуправляемой или просто ждет спасения со стороны.
Организовывать устранение, а не выполнять мелкие поручения
Руководство по Scrum 2020 года подчеркивает, что Scrum Master служит команде, способствуя устранению препятствий. Там не сказано, что Scrum Master обязан устранять каждую проблему лично. Когда разработчику нужны доступы к тестовому серверу, неэффективный Scrum Master сам заводит заявку в службу поддержки. Опытный Scrum Master выясняет, почему для выдачи доступов вообще требуется административная заявка, или помогает разработчику запросить доступ напрямую.
Превращение Scrum Master в курьера для административных задач лишает Developers самостоятельности. Если препятствие находится в пределах внутренних границ команды, Developers должны справиться с ним сами. Scrum Master подключается тогда, когда источник проблемы кроется в масштабах всей организации, где у команды нет полномочий для структурных изменений.
Классификация препятствий по зонам контроля и влияния
Чтобы устранять препятствия системно, необходимо понимать, где находится источник проблемы. Любое препятствие относится к одной из трех зон:
- Прямой контроль. Проблемы внутри Scrum Команды, такие как задержки код-ревью или слабые критерии приемки, которые команда способна устранить немедленно.
- Прямое влияние. Трения при взаимодействии с непосредственными партнерами, например, общие тестовые среды под управлением другой группы, что требует сотрудничества и переговоров.
- Организационная архитектура. Политики компании, регламенты закупок или изоляция подразделений, изменение которых требует вмешательства руководства.
Когда возникает препятствие, классифицируйте его перед началом действий. Если вы воспринимаете организационное ограничение как командную задачу, вы теряете время. Если вы эскалируете внутреннюю проблему коммуникации высшему руководству, вы наносите ущерб автономии команды.
Сделайте стоимость задержки наглядной
Организации часто игнорируют проблемы до тех пор, пока те не повлекут за собой явные финансовые потери. Если ваша команда тратит по три дня на ожидание согласования от службы безопасности в каждом спринте, жалобы на Retrospective вряд ли изменят позицию менеджмента. Руководители нередко списывают такие претензии на обычное ворчание инженеров.
Чтобы переломить эту ситуацию, выразите потери в цифрах. Отслеживайте потерянные часы, сорванные Sprint Goals и затраты на зарплату за время вынужденного простоя. Разместите эти данные на доске препятствий в общем пространстве. Когда заинтересованные лица увидят, что долгие проверки безопасности обходятся в пятьдесят тысяч долларов задержек каждый квартал, руководство службы безопасности найдет способ автоматизировать свои регламенты.
Воздействуйте на систему, а не на отдельный тикет
Типичная ошибка заключается в восприятии регулярных препятствий как единичных случаев. Допустим, вашему администратору баз данных требуется четыре дня на запуск скриптов миграции схемы. Scrum Master из лучших побуждений может наладить личный контакт с администратором, чтобы продвигать задачи своей команды вне очереди.
Это попытка обойти очередь, а не устранение препятствия. Первопричина дисфункции остается нетронутой. Эффективное устранение требует ответа на вопрос, почему ручная проверка миграций вообще существует. Вы работаете с администратором над созданием автоматических проверок безопасности, встраиваете тесты миграций в пайплайн сборки и ликвидируете саму очередь. Устранить препятствие означает сделать так, чтобы оно больше не повторилось.
Раннее выявление препятствий на Daily Scrum
Daily Scrum не является встречей для отчетов о статусе. Это рабочая сессия для инспекции прогресса на пути к Sprint Goal и адаптации плана на день. За пятнадцать минут встречи Developers должны выявить зарождающиеся препятствия еще до того, как они превратятся в непреодолимые барьеры.
Дисциплинированная команда не ждет полной остановки работы, чтобы заявить о проблеме. Если разработчик замечает, что время ответа API деградирует или сторонняя команда не выходит на связь, он сообщает об этом сразу. Команда корректирует свой ежедневный план, чтобы обойти препятствие, пока Scrum Master принимает меры для его окончательного устранения.