Кто такой scrum-мастер?

Описание. Scrum-мастер поддерживает в команде культуру scrum и следит за соблюдением ее принципов. Этот человек во всем следует ценностям и методикам scrum, при этом действует гибко и всегда готов использовать новые возможности на благо рабочего процесса команды.

Как следует из названия, такой человек действительно мастер, он в совершенстве владеет методами scrum и может сделать так, чтобы остальные тоже придерживались этого подхода. Метод scrum предписывает четкие роли и ритуалы. Scrum-мастер работает с каждым участником scrum-команды, предоставляя необходимые инструкции и ведя обучение с целью добиться воплощения принципов scrum.

Недавно компания Atlassian провела опрос в Twitter, который показал, что 92 % респондентов применяют собственные методы и подходят к правилам Scrum избирательно. Тогда мы задумались: что это означает для Scrum-мастеров, которые должны инструктировать команды и помогать им понять метод Scrum? Какова их роль в постоянно меняющемся agile-мире, где действуют «не по уставу»?

На эти вопросы мы хотели получить ответы, когда углубились в изучение ролей и обязанностей скромных героев agile — scrum-мастеров.

Scrum-мастера — это фасилитаторы scrum, легковесной agile-платформы, которая фокусируется на сгруппированных по времени итерациях, называемых спринтами. Как и фасилитаторы, scrum-мастера выступают в качестве коучей для остальной части команды. Руководство по scrum называет их «лидерами-служителями». Хорошие scrum-мастера преданы основам и ценностям метода scrum, но остаются гибкими и показывают команде возможности для улучшения рабочего процесса.

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

1. Стендапы. Практикуйте ежедневные стендапы, или scrum-совещания, по мере необходимости.
2. Собрания по планированию спринтов или итераций. Берегите команду от чрезмерной нагрузки и расширения области работы. Участвуйте в оценке работы и разбивайте ее на подзадачи.
3. Обзоры итогов спринтов. Принимайте участие в совещаниях и фиксируйте обратную связь.
4. Ретроспективы. Отмечайте, что можно улучшить, и планируйте конкретные действия на следующий спринт.
5. Администрирование досок. Станьте администратором доски scrum. Поддерживайте карточки в актуальном состоянии, а инструмент scrum (например, Jira Software) — в рабочем.
6. Встречи один на один. Разговаривайте индивидуально с каждым участником команды и заинтересованными сторонами, если необходимо. Улаживайте разногласия по поводу процессов и стиля работы в команде. Многие специалисты scrum против встреч один на один, поскольку убеждены, что все должно обсуждаться во время стендапов. Однако участники многих, особенно новых, команд предпочитают регулярно встречаться с определенными коллегами один на один. Scrum-мастер может признать, что такие личные встречи важны для развития команды и знакомства ее участников друг с другом.
7. Внутренние консультации. Scrum-мастерам следует быть готовыми к обмену мнениями с другими участниками команды и внутренними заинтересованными сторонами, чтобы вместе решать, как лучше организовывать работу scrum-команды.
8. Отчеты. Регулярно анализируйте диаграммы Burndown и другие инструменты планирования портфеля, чтобы понимать, какие сборки готовы и как часто выполняются релизы.
9. Блокеры. Scrum-мастер устраняет внешние блокеры и помогает команде справляться с внутренними препятствиями, улучшая рабочие процессы.
10. Интенсивная работа. Если scrum-команда не погружена в рабочий процесс, это сигнал для scrum-мастера. Возможно, стоит починить сломанные компьютеры, передвинуть столы или, может быть, просто отрегулировать температуру в офисе. Scrum-мастер должен быть готов создавать условия для работы команды любыми подходящими способами — даже принести кофе и что-нибудь перекусить, если это решит проблему.

Любой scrum-тренер учит, что в scrum-команде должен быть scrum-мастер. Без него вы будете работать не совсем так, как предполагает подлинный scrum. Подобную ситуацию часто называют «скрам-бат» (scrum-but).

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

Но все scrum-команды разные. Многие опытные команды выполняют все перечисленные обязанности, действуя как единое целое. Они гордятся и наслаждаются совместным управлением процессом. Роль scrum-мастера дрейфует между участниками команды, которые проводят стендапы и ретроспективы по очереди.

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

К сожалению, неправильное понимание роли scrum-мастера часто приводит к тому, что существующие менеджеры начинают считать эти обязанности своими. Чтобы лучше понять, почему это может вылиться в проблему, давайте сравним роль scrum-мастера с ролями, не относящимися к scrum, которые, возможно, уже есть в вашей организации, и обсудим, почему важно не смешивать эти роли.

В обзоре управления проектами по методике agile мы отстаиваем такую точку зрения: чем больше менеджер по продукту будет вовлечен в работу команды разработчиков, тем лучше. Однако ему следует выступать в роли владельца продукта и защищать потребности клиента. Он должен отвечать на вопрос «зачем» в отношении целей разработки. Проблемы начинаются, когда менеджер по продукту составляет списки заданий для команды и ищет ответы на вопрос «как». Такая установка, даже при благих намерениях, приводит к дефектам, перепоручениям и неопределенности. Смешение таких уровней управления, как направление разработки и рабочий процесс, ведет к потере направления, нарушению графика работы и ухудшению качества. Это путь к провалу.

Вот почему владелец продукта и scrum-мастер должны играть в scrum-команде две разные роли. Однако при традиционном управлении разработкой эти роли часто соединяются в одном лице. Да, в небольших командах велико искушение избежать очевидных расходов на второго специалиста. Однако если появляются препятствия или неизбежны изменения, необходимо четко разделять управление процессом разработки и развитием продукта.

Нетехническим (или не относящимся к agile) двойником scrum-мастера является менеджер проекта. Обе эти роли концентрируются на том, «как» выполнить работу и решить проблемы рабочего процесса через управление им и координацию. Нужны ли вам обе эти роли? Скорее всего, нет.

И традиционный менеджер проекта, и scrum-мастер помогают команде в выполнении работы, но их подходы очень разные. Менеджер проекта устанавливает и отслеживает временные рамки и контрольные точки, сообщает о прогрессе и координирует взаимодействие в команде. Вместе с тем он делает это с позиции контроля, играя более традиционную управленческую роль.

Scrum-мастер помогает команде улучшать и оптимизировать процессы, с помощью которых она достигает своих целей. Он действует как один из команды, как участник общего дела и в идеале не руководит в традиционном смысле слова. Лучшие scrum-команды практикуют самоорганизацию и потому плохо реагируют на управление «сверху вниз».

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

При найме scrum-мастера стоит принять во внимание еще одно очень важное соображение. Делайте это только в случае, если организация активно настроена на работу по методу scrum и инвестирует в этот процесс. Все вышеперечисленные роли могут управлять командой разработчиков множеством способов, но scrum-мастер эффективен только при абсолютной приверженности методу scrum. Этим все сказано.

Благодаря scrum-мастеру, который помогает каждой команде управлять процессом, организация в целом может получить несколько серьезных преимуществ. Помимо регулярной поставки ценного продукта клиентам (основная цель scrum), участники команды и менеджеры смогут сосредоточиться на том, что они делают лучше всего. Менеджеры по продукту могут сфокусироваться на стратегии, разработчики получат возможность написать свой лучший код, а Кайл из отдела продаж наконец-то совершит звонок, до которого не доходили руки. На что это похоже? Это похоже на высокофункциональный scrum, музыку для наших ушей.