В этой статье мы разберёмся с тем, должен ли scrum-мастер решать все проблемы, с которыми сталкивается команда? Часто команда нагружает своего scrum-мастера разными задачами: часть из них входят в его обязанности, а другая часть — превращает scrum-мастера в няньку.
Scrum-мастер работает на полный рабочий день, и в его круг обязанностей входит так называемое «устранение препятствий». Из-за того, что это весьма абстрактная формулировка, scrum-мастер рискует получить задачи, которые не входят в его компетенцию.
Scrum Guide описывает роли, которые играет scrum-мастер в команде. Одной из них является устранение препятствий на пути команды разработчиков. На первый взгляд, это, кажется, заставляет нас ответить «Да» на вопрос из темы статьи. Но «препятствие» является здесь ключевым словом. Слишком часто окружающие думают, что препятствия — это любые проблемы, задачи, которые не охота делать, и раздражающие мелочи. И нам кажется, что это не тот путь, которым следует идти самоорганизованным командам.
Помощь vs. Самоорганизация
Препятствия — это такие проблемы, которые мешают прогрессу команды и не могут быть решены самими разработчиками, или для их решения понадобится много времени, но не квалификации, но они не касаются цели спринта. Это определение связано с другой концепцией Scrum — самоорганизацией команды.
Во время разработки может возникнуть немало проблем, которые как связаны с продуктом, так и не связаны с ним:
- болезнь одного из членов команды,
- сложности со средой разработки, разрешениями,
- сломанная или отсутствующая техника, тестовое устройство,
- конфликт внутри команды,
- конфликт со стейкхолдерами,
- недоступность владельца продукта и т. д.
Самоорганизация — это способность команды решить проблему без необходимости делегировать её людям вне группы разработки. Преодолевая «препятствия» (будь то налаживание среды разработки или решение группового конфликта), команда повышает свою квалификацию.
Является ли команда самоорганизующейся, если проблемы она привыкла решать только через scrum-мастера? Если команда не может решить вопросы сама, scrum-мастер является bus-фактором этой команды. Гиперопека препятствует развитию команды. Часть проблем корнями уходит куда глубже, так что помощь scrum-мастера окажется лишь временным решением. Это могут быть проблемы в организации работы, в общении внутри команды или несоответствии ценностям Scrum.
Scrum-мастер должен анализировать ту помощь, которую оказывает своей команде. Ему нужно исследовать, почему это происходит, и поднимать важные ситуации на ретроспективе. В идеале, scrum-мастер должен повысить способность команды решать проблемы самостоятельно. То, что было проблемой на первых спринтах, команда может сама решить в десятом спринте — если это так, то scrum-мастер проделал хорошую работу.
Scrum-мастер — это часть команды. Он помогает там, где это целесообразно и возможно. Например, если нужно исправить какую-то поломку или разобраться с бюрократией, это рациональнее сделать scrum-мастеру, чтобы не отвлекать команду от рабочего процесса.
Вот несколько ценных принципов и подсказок из статьи Myth 7: The Scrum Master Must Resolve Every Problem:
- Scrum-мастер подсказывает, а не решает,
- Обсуждение острых препятствий не должно ждать стенд-апа или дейли, а проводиться незамедлительно,
- Прежде, чем браться за решение проблемы, Scrum-мастеру нужно спросить себя: «Что произойдёт, если я ничего не сделаю? Кто-нибудь из команды позаботится об этом?»
- Используйте «Доску препятствий», чтобы собирать проблемы от команды, но убедитесь, что используете её для реальных препятствий, а не для делегирования всякой рутины.
- Используйте цель спринта, чтобы оценивать важность проблем и приоритизировать их.
- Сотрудничайте с владельцем продукта, так как большинство препятствий будут связаны с продуктом, бизнес-процессами и стейкхолдерами.
- Если команда теряет самостоятельность, используйте приём «тишины» — «молчи и смотри, что будет дальше». В этом случае, в качестве эксперимента не устраняйте препятствие, а посмотрите, что будет делать команда.
- Решайте реальную проблему, а не первую.
Таким образом, Scrum-мастер не отвечает за решение всех проблем. Вместо этого, он помогает команде стать более самостоятельной с минимальными «травмами».
Что вы думаете на эту тему? Как построен процесс в вашей команде, какие проблемы традиционно решает scrum-мастер, а какие в поле ответственности команды?
