Scrum-мастер — это младший agile-коуч?

На Scrum.org рассматривают интересную тему: всегда ли scrum-мастер — это первая ступень к agile-коучу, или это миф?

Это перевод статьи Барри Оверима (с разрешения автора), которая развеет убеждение, что между ролью scrum-мастера и agile-коуча есть границы.

Вы scrum-мастер и готовы на следующий шаг — стать коучем? Вашей организации нужен agile-коуч, потому что scrum-мастер фокусируется только на команде? У вас есть опыт работы в качестве scrum-мастера и вы хотите пройти трёхдневный курс, чтобы стать тренером? Правда, что, чтобы больше получать, нужно перейти от scrum-мастера к статусу agile-коуча?

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

Этот миф касается нас по ряду причин:

• Он основан на искажённом или неполном понимании того, что именно делает scrum-мастер на самом деле и что он должен делать в соответствии с фреймворком Scrum;
• Он позиционирует agile-коуча выше в иерархии, особенно в организациях, где рост определяется вертикально. Тогда scrum-мастер — это Junior, agile-коуч — Middle, а enterprise-коуч — Senior.
• Тренинговые фирмы тоже поощряют такой образ мышления, потому что он хорошо сочетается с ростом платы за программы обучения.

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

Разрушаем миф

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

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

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

Ещё один полезный взгляд на роль scrum-мастера предлагается в статье «8 позиций scrum-мастера». В ней описываются различные обязанности этой роли в восьми действиях, которые тесно связаны с Scrum Guide:

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

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

Работа со «старшинством»

«Хороший scrum-мастер помогает команде выжить в культуре организации. Великий scrum-мастер помогает изменить культуру, чтобы команды могли процветать» — Джефф Уоттс.

Scrum Guide и статья «8 позиций scrum-мастера» говорят о проблемах, которые решает scrum-мастер:

• Как помочь людям перейти от плановых подходов к эмпирическому процессу, который более справедливо учитывает сложность работы, которую они выполняют?
• Как облегчить прозрачность, инспекцию и адаптацию в традиционной «закрытой» организации?
• Как коучить организации, которые действительно сотрудничают со своими scrum-командами?
• Как управлять границами самоорганизации в организациях с подконтрольной структурой?
• Как предложить «безопасную для неудач и обучения» среду, где проводятся эксперименты?
• Как продвигать культуру, в которой scrum-команды могут процветать?

Являясь scrum-мастером, вы имеете дело с этими трудными задачами и влияете на культуру организации таким образом, чтобы ...

• успех команды оценивался выше индивидуальных успехов,
• поддерживалось непрерывное совершенствование и экспериментирование,
• поощрялось финансирование по гибким контрактам,
• поддерживался стабильный состав команд.

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

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

Совместная работа нескольких scrum-мастеров способна запустить организационные изменения изнутри. С точки зрения команды, scrum-мастер действительно является «агентом изменений».

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

Теперь уволить всех agile-тренеров?

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

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

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

Наши советы для организаций:

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

Что делать, если мы используем Kanban / XP / DevOps?

Scrum — это всего лишь одна основа для повышения гибкости организации. Scrum не является самоцелью. Независимо от того, какой фреймворк или методологию вы выберете, это приведёт к организационным изменениям. Люди, которые могут проводить изменения, являются частью команд, которые делают свою работу. Их можно назвать scrum-мастер, бог Kanban, XP-чувак, DevOps-гуру — это неважно.

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

Что вы думаете об этом мифе и каков ваш опыт?