Практические шаблоны устранения препятствий
Практические подходы к выявлению, эскалации и устранению реальных препятствий, которые помогут вашей Scrum-команде поддерживать поток работы и предсказуемо поставлять ценность.
Большинство команд воспринимают препятствия как неприятные неожиданности. Разработчик сообщает на Daily Scrum, что нет нужных доступов, или тестовое окружение упало за ночь. Работа останавливается, раздражение растет, и все ждут, пока Scrum Master придет на помощь. Такая реактивная позиция неэффективна. Препятствием считается все, что замедляет работу команды или мешает достичь Sprint Goal. Чтобы поддерживать стабильный поток ценности, вам нужны надежные практики для выявления, оценки и устранения таких блокеров до того, как они сорвут Sprint.
Отделяйте блокеры от повседневных задач
Не каждая трудность является препятствием, требующим внешнего вмешательства. Разработка программного обеспечения по своей природе сложна, а решение трудных технических задач входит в обычные обязанности Developers. Если разработчик сталкивается с неочевидным алгоритмом или хитрой ошибкой, это нормальная инженерная работа. Слишком раннее вмешательство лишает Developers самоорганизации.
Препятствие возникает тогда, когда работа останавливается из-за сложностей, с которыми команда не может справиться самостоятельно, или когда проблема угрожает Sprint Goal. Сломанный инструмент запуска тестов, отнимающий половину рабочего времени команды, является препятствием. Трехдневное ожидание токена безопасности тоже является препятствием. Первый шаблон заключается в простой категоризации: позвольте команде справляться с техническими сложностями, но решительно вмешивайтесь, когда системные проблемы блокируют работу.
Организуйте устранение, а не делайте чужую работу
Руководство по Scrum (Scrum Guide) говорит, что Scrum Master служит Scrum-команде, способствуя устранению препятствий на пути ее прогресса. Обратите внимание на формулировку. В руководстве не сказано, что Scrum Master обязан лично решать каждую проблему. Когда Scrum Master превращается в административного курьера, он сам становится узким местом. Команда при этом теряет возможность учиться взаимодействовать с организацией.
- Поощряйте Developers решать внутренние зависимости напрямую через короткие обсуждения.
- Знакомьте Developers с нужными внешними заинтересованными сторонами вместо того, чтобы работать посредником.
- Вмешивайтесь лично только тогда, когда команду блокируют организационная бюрократия, конфликт приоритетов или политика компании.
Сделайте препятствия видимыми на доске
Невидимые препятствия незаметно истощают ресурсы команды. Если о блокерах знают только в приватном чате или держат их в памяти, организация не видит цену задержек. Проверенный подход заключается в том, чтобы фиксировать блокеры прямо в Sprint Backlog, куда вся команда смотрит каждый день.
Прикрепляйте к элементам на доске визуальную метку блокера. Указывайте дату возникновения проблемы, ответственного за следующий шаг и конкретное решение, необходимое для ее устранения. На Daily Scrum проверяйте такие элементы в первую очередь. Когда стейкхолдеры видят накапливающиеся заблокированные задачи, реальную цену внутренних трений становится невозможно игнорировать.
Выстройте четкий маршрут эскалации
Многие препятствия находятся вне зоны влияния Scrum-команды. Задержки внешних подрядчиков, согласования со службой безопасности и ограничения общей инфраструктуры требуют подключения руководства. Без понятного пути эскалации такие вопросы неделями кочуют по почтовым перепискам.
Создайте прозрачную договоренность с руководством о том, как и когда нужно эскалировать проблемы. Если внешняя группа не отвечает в течение 24 часов, Scrum Master передает вопрос напрямую назначенному руководителю подразделения. Излагайте факты прямо: объясните, какая именно Sprint Goal находится под угрозой, посчитайте стоимость простоя и запросите точечное решение. Четкие экономические аргументы устраняют бюрократические задержки гораздо быстрее, чем эмоциональные жалобы.
Устраняйте первопричину после временного решения
В разгар Sprint команды часто используют временные обходные пути, чтобы не останавливаться. Разработчик берет доступы у коллеги или тестирует вручную из-за сбоя автоматизации. Обходные пути помогают защитить текущую Sprint Goal, но не являются постоянными решениями. Если остановиться на этом, то же препятствие вернется в следующем Sprint.
Используйте Sprint Retrospective для поиска первопричин повторяющихся блокеров. Если выдача доступов заняла четыре дня, разберитесь, почему этот процесс устроен именно так и кто за него отвечает. Работайте с руководством над автоматизацией доступов или передачей права согласования команде. Разовое устранение препятствия полезно, но настоящим улучшением становится перестройка процесса, которая исключает повторение проблемы.