agile

Нужен ли технический бэкграунд Скрам-мастеру?

Нанять профессионала с рынка или выбрать из участников команды? Разбираем критерии выбора Скрам-мастера.

ДЛ
Дмитрий Лобасев
6 апреля 2021 г.
Полезна?

Нужен ли технический бэкграунд Скрам-мастеру? Короткий ответ - зависит от этапа развития команды.

Если команда только запускается, наличие у Скрам-мастера технического бэкграунда будет плюсом. Практика показывает, что при запуске команда нередко обращается к Скрам-мастеру с проблемами, касающимися реализации (например, не можем поставить стенд для микросервисов) или коммуникации с бизнесом. И важно, чтобы Скрам-мастер понимал, какого плана проблема и как помочь команде ее решить.

По мере взросления команды это влияние снижается и практически не имеет значения, когда команда достигла определенной самоорганизации.

А что делать при найме Скрам-мастера?

Идеальный вариант - выбрать Скрам-мастера из состава команды, чтобы человек совмещал свою обычную роль в команде и роль скрам-мастера.

Но даже если вы берете человека с рынка, его технический бэкграунд должен стать важным плюсом при выборе кандидата.

Даже компаниям в активной фазе трансформации, когда сразу формируются десятки команд и соответственно десятки вакансий, мы рекомендуем набирать Скрам-мастеров не всем скопом (частый аргумент здесь — «потому что в Сбере их сотни»), а все-таки ориентируясь на конкретные команды и их состав.

Повторимся, что в идеале, Скрам-мастер должен участвовать в разработке продукта наравне с остальными участниками команды, а не просто быть Мастером Скрама.

Плюсы и минусы выбора

О деталях выбора Скрам-мастера рассказывает старший консультант OnAgile Consulting Артём Гринякин. «Выбрать Скрам-мастера из команды или привлечь специалиста со стороны — это всегда дилемма. И как у любой монеты есть орел и решка, так и в этом вопросе стоит разобраться и посмотреть, какие плюсы и минусы имеются в наличии».

Скрам-мастер выбирается или назначается из участников команды (совмещение с ИТ-позицией)

Минусы

  • Непонимание своей роли и недостаточная погруженность в Agile-подходы
  • Потенциальные конфликты в команде по принципу «почему он, а не я?»
  • Отсутствие опыта в решении конфликтных ситуаций
  • Невозможность предоставить сервис поддержки Владельцу продукта
  • Отсутствие навыков фасилитации, коучинга, обучения
  • Отсутствие ответов на базовые вопросы, которые часто возникают у новых команд
  • Необходимость постоянно балансировать между ИТ-ролью и Скрам-мастерством
  • Отсутствие мутации на уровне команды. Это теория, которая подразумевает, что из одного набора генов (специалистов) невозможно качественно вырасти без привлечения свежей крови (мутации) — новых специалистов, не входящих в состав изначальной группы.

Плюсы:

  • Погруженность в предметную область
  • Более эффективное использование ресурсов с точки зрения бизнеса

Скрам-мастер привлекается со стороны

Минусы:

  • Временное непонимание предметной области
  • Время на адаптацию и первоначальный анализ

Плюсы:

  • Новые знания, подходы, которые раньше не присутствовали в организации
  • Навыки фасилитации, коучинга, обучения
  • Вариативность в методах и практиках
  • Умение ответить на базовые вопросы
  • Отсутствие конфликта интересов
  • Возможность погрузиться в процесс развития команды и организации
  • Предоставление сервиса поддержки Владельцу продукта
  • Возможность балансирования Бизнеса и ИТ
  • Умение решать конфликты
  • Возможность взять до 3 команд (актуально для LeSS и производных от SAFe, где считается оптимальным использование одного Скрам-мастера на 3 команды. В немасшабируемом Scrum такой подход не приветствуется)

Важный момент: чем менее зрелая команда, тем в большем вовлечении Скрам-мастера она нуждается. И соответственно, с развитием это внимание, выраженное в часах, снижается.

Частые вопросы
Почему опытные Скрам-мастеры считают технический бэкграунд критически важным на старте команды?
На начальном этапе команда часто обращается к Скрам-мастеру с техническими проблемами - от настройки инфраструктуры до коммуникации с бизнесом. Без технического опыта Скрам-мастер не сможет эффективно помогать команде преодолевать эти препятствия. По мере роста зрелости команды значимость технического бэкграунда снижается.
Какую неожиданную ошибку допускают компании при массовом найме Скрам-мастеров?
Компании часто набирают Скрам-мастеров 'всем скопом', ориентируясь на опыт крупных банков. Это серьезная ошибка - успешные трансформации показывают, что Скрам-мастера нужно подбирать индивидуально под каждую команду, учитывая её текущий состав и уровень зрелости.
Как выбор внутреннего Скрам-мастера может навредить команде?
Внутренний Скрам-мастер часто сталкивается с конфликтом интересов, пытаясь совмещать две роли. Команда может не воспринимать его как авторитет, возникают конфликты по принципу 'почему он, а не я'. Отсутствие опыта в фасилитации и коучинге также существенно ограничивает эффективность работы.
Почему успешные компании предпочитают брать Скрам-мастеров со стороны?
Внешний Скрам-мастер приносит новые знания и практики, которых нет в организации. Он может непредвзято решать конфликты, эффективно балансировать интересы бизнеса и разработки, а также масштабировать свой опыт на несколько команд, что особенно ценно в LeSS и SAFe фреймворках.
Какой секрет повышения эффективности команды знают опытные Скрам-мастеры?
Ключевой фактор - это принцип мутации команды. Без привлечения 'свежей крови' и новых специалистов команда не может качественно развиваться, даже при наличии сильных внутренних экспертов. Внешний Скрам-мастер становится катализатором таких позитивных изменений.
Как определить оптимальную загрузку Скрам-мастера?
Загрузка напрямую зависит от зрелости команд. Незрелым командам требуется максимальное внимание и полная занятость Скрам-мастера. С ростом самоорганизации команд один Скрам-мастер может эффективно поддерживать до трех команд одновременно.
"Каждый проект начинается с разговора о задаче. Часто за исходным запросом кроется большой организационный контекст, который нужно изучить для правильного решения задачи. Поэтому мы много спрашиваем на старте."
Дмитрий Лобасев, управляющий партнер OnAgile

Сначала слушаем, задаём вопросы, разбираемся в ситуации. Потом предлагаем подход и только тогда обсуждаем условия.

Расскажите о вашей задаче