Вокруг роли scrum-мастера возникает множество вопросов. Один из самых распространённых: насколько удачно использование переходящей роли scrum-мастера?
Есть несколько реализаций этого:
- каждый в команде поочередно совмещает свою роль и роль scrum-мастера, участники меняются каждый спринт,
- у команды часто меняется scrum-мастер.
Пока мы не перешли к доводам «за» и «против», ответим кратко:
- Да, можно работать с переходящей ролью scrum-мастера.
- Это хуже, чем работать с постоянным scrum-мастером.
Руководство по Scrum не запрещает ни совмещение роли, ни её переходящий статус. Вы не нарушаете теорию, если поступаете таким образом.
Если обстоятельства складываются так, что не получается нанять постоянного scrum-мастера, это будет выход, «лучше, чем ничего».
С другой стороны, сама идея того, что роль можно передавать друг другу, основывается на чём-то из двух:
- глубоком понимании командой принципов гибкой разработки, так что команда стала самоорганизующейся (редкий вариант),
- неправильное понимание роли scrum-мастера (частый вариант).
Если scrum-мастер в компании — это человек, который только:
- печатает сценарии для scrum-событий и ведёт записи после них,
- озвучивает три вопроса на стендапе,
- записывает истории на стикеры и рисует диаграмму,
- расставляет события по календарю,
- ведёт расписание спринта и отмечает отсутствие членов команды,
- обновляет программы, синхронизирует аналоговую доску с цифровой, пишет отчёт по спринту...
то эту роль действительно хочется поменять. Наверное, он ещё заказывает канцелярию, держит большую коробку стикеров и фломастеров. Это секретарь, а не scrum-мастер. Такие обязанности можно передавать другим без ущерба для их качества.
Описанные выше задачи — это действительно то, что делает scrum-мастер. С этого начинают многие организации. Но это не главные его обязанности, в идеале, мы хотим от scrum-мастера больше. Прикладные задачи помогают команде, но не на том уровне, чтобы выделять это в отдельную роль во фреймворке.
Что же можно упустить?
Передавая роль scrum-мастера, команда может упустить осмысленное проведение scrum-событий и глубокое следование agile-принципам. Поверхностные действия приводят к поверхностному следованию фреймворку.
Образно говоря, scrum-мастер привносит дух Scrum. Он помогает команде следовать целям, исследовать реальное влияние Scrum на разработку и оценивать работу со стороны.
Без постоянного scrum-мастера команда лишается:
- ответственного за принятие Scrum, который проверяет соответствие теории фреймворка, правилам и принципам гибкой разработки,
- независимого защитника команды,
- лидера, который отвечает за рост каждого человека в команде, за совершенствование методов и за сотрудничество бизнеса и scrum-команд,
- управления scrum-процессом и культурой внутри команды.
Без отдельной роли scrum-мастера владельцу продукта и команде будет трудно выполнять эти функции полноценно. Если упускать такие вещи, как поддержание Scrum или развитие командной работы, организация добьётся меньшего успеха.
Совет 1: не меняйтесь ролью scrum-мастера. Возможно, вашей команде кажется, что есть объективная причина, почему у вас нет этой роли. Посмотрите на выгоды и на свои ожидания от этой роли.
Совет 2: если в команде всё равно не предвидится scrum-мастер, придётся стать действительно самоорганизованной командой. Более глубокие обязанности scrum-мастера нужно расшарить между всеми в команде, строго оценивать себя на ретроспективах. организовывать своё развитие и проводить совместные проверки. В целом, всей команде придётся заменить одного scrum-мастер. Переходящими могут быть обязанности секретаря, которые мы перечислили выше.
Что вы думаете по теме? Как роль scrum-мастера принимается в вашей организации? Если вы используете модель с переходящей ролью, какие проблемы и преимущества вы находите в этом?
