Интересный вопрос, который я неоднократно встречаю с самых первых дней практики и «евангелизации» Scrum подхода. Действительно, для маленьких команд от 5 до 9 человек (как предписывается), да еще и в аутсорсинге (как бывает) нанять отдельного выделенного ScrumMaster может быть проблемой. Бывает, что роль не до конца понятна команде и заказчику/менеджменту. А бывает, что банально не хватает денег на хорошего опытного ScrumMaster’а, который «разгонит» и оптимизирует команду –  поможет ей достигнуть небывалых высот.

В любом случае, многие приходят к казалось бы логичной идее совместить эту роль с технической ролью в команде. Тем самым получить продуктивного игрока, который лишь половину времени уделяет ScrumMaster’ству, а остальное время приносит пользу делает что-то в другой роли (разработчик, тестировщик, бизнес-аналитик и т.п.).

Давайте рассмотрим примеры такого совмещения, какие бывают плюсы и минусы и как можно расставлять приоритеты.

Пример первый, ScrumMaster-разработчик.

Пожалуй, самый популярный пример. Берем опытного разработчика (его еще по старинке могли называть Team Lead), и называем его ScrumMaster. Можем даже на тренинг послать, чтобы знал, что делать.

И сразу возникает интереснейшая ситуация!

Как разработчик, да еще и опытный, наш герой должен взять на себя самые важные задачи (по приоритетам, разумеется) и помочь команде тем, что сделает их. Иначе остальные потратят на это кучу времени, и команда в целом не будет такой эффективной. Во всяком случае, примерно так обычно и мыслят.

С другой стороны, как ScrumMaster, наш герой должен помочь команде сфокусироваться, не тратить лишнее время на ритуалах, понять, где теряется время, и как мы можем быть более эффективными, обеспечить прозрачность и еще много чего другого. Т.е. на мой взгляд, этот аспект работы требует совершенно перпендикулярного фокуса по сравнению с ролью разработчика.

Из явных плюсов то, что такой ScrumMaster разбирается в деталях задач, может подсказать лучшее решение или хотя бы увидеть, когда команда технически не эффективна. Также он может быть евангелистом инженерных практик в дополнение к Scrum.

Из явных минусов – жесткий конфликт приоритетов между ролями. С одной стороны сфокусироваться и уйти в задачу == помочь команде, с другой стороны защитить команду от отвлечений == помочь команде. Баланс держать невероятно трудно, и чтобы быть хорошим СкрамМастером, нужно сознательно пересмотреть отношение к роли разработчика.

В моем опыте были успешные примеры, когда разработчики в первую очередь фокусировались на роли ScrumMaster и всячески помогали команде с этой стороны, а оставшееся время тратили на техническое менторство; настройку инфраструктуры, т.е. тоже экономию времени команды, обычно менее критическую по приоритетам; и даже координацию совместных технических решений, хотя тут важно избежать синдрома «я самый умный». Это требует определенной зрелости разработчика, как профессиональной, так и морально-психической.

К сожалению, часто встречаю негативные примеры совмещения роли ScrumMaster и разработчика. Особенно, если это ведущий разработчик и в прошлом назывался Team Lead, т.е. подразумевались некие расширенные полномочия. В этом случае новая роль ScrumMaster рассматривается как еще одна карьерная ступенька (и закрепляет «корону»), а отнюдь не как роль по улучшению командной работы.

Для краткости статьи я привел лишь основные, на мой взгляд, доводы, если у вас есть свои мысли о таком совмещении – оставляйте комментарии.

В следующих статьях я рассмотрю другие примеры совмещения ролей: ScrumMaster-QA (Тестер), ScrumMaster-Бизнес аналитик, ScrumMaster-Менеджер. Следите за нашими обновлениями.