Фреймворк Scrum, согласно исследованиям scrumtrek.ru, используют в работе более 50% организаций, работающих с Agile-подходами. На данный момент Scrum самый популярный подход, нравится вам это или нет. Можно пытаться бороться с ним, можно избегать, можно принять этот факт как данность и  разобраться — возможна ли действительно эффективная работа в таком стиле, что нужно для этого делать, как проверять и корректировать свои действия? Роль Scrum-мастера ключевая в выстраивании рабочих процессов в команде, но при этом официальное руководство описывает что должен делать СМ, и ничего не говорит как именно нужно это делать. Можно ли вообще как-то измерить работу Scrum-мастера и понять, приносит ли он пользу команде и организации в целом, или это только "yet another role"? На сегодняшний день самый популярный и распространённый метод гибкого (Agile) управления разработкой — Scrum. Одна из трех ролей в нём — Scrum-мастер (Скрам-мастер, СМ): человек, который ответственен за пункт "как мы работаем". Является ли Scrum-команда действительно самоуправляемой и автономной командой, прозрачны ли все процессы, своевременно ли выявляются и устраняются все препятствия? Может быть нужно добавить другие практики, не входящие в Scrum, или даже что-то изменить, если оно не прижилось в команде? Надо отметить, что СМ отвечает в большей степени за эффективность операционной деятельности, потому что стратегия и бизнес-результаты лежат в зоне ответствености другой роли. Организованная и сплоченная Scrum-команда может, несмотря на отлично выстроенные процессы, довольно легко и быстро разорить заказчика или привести к провалу продукта на рынке. Scrum допускает, что кто-то из команды разработчиков может взять на себя эту роль, но обычно это либо отдельный сотрудник компании, назначенный (или вызвавшийся добровольно) на эту роль с неким опытом за плечами (чаще всего не техническим), либо специально нанятый для этого специалист. И раз уж в команде есть такой человек, и от него во многом зависит весь рабочий процесс, неплохо бы знать — насколько он полезен для компании, правильное ли у него "шаманство" там внутри команды?   Вкратце, Scrum требует, чтобы Scrum Master способствовал возникновению среды, в которой: 1. Product Owner упорядочивает работу по решению комплексной проблемы в Product Backlog. 2. Scrum Team в ходе Sprint превращает выбранную работу в Increment, несущий ценность. 3. Scrum Team и заинтересованные лица инспектируют результаты и вносят правки для  следующего Sprint. То есть, за построение правильного "процессного окружения" отвечает именно SM, не только в рамках работы разработчиков, но и включая деятельность Product Owner. Причем, как видно далее из руководства, это ответственность SM в идеале распространяется за пределы Scrum-команды, и охватывает процессы всей организации.   Scrum Master несет ответственность за применение Scrum в соответствии с Руководством по Scrum. Они делают это, помогая всем понять теорию и практики Scrum, как внутри Scrum Team, так и в организации.Scrum Master отвечает за эффективность Scrum Team. Он делает это, помогая Scrum Team улучшать свои методы работы в рамках фреймворка Scrum.Scrum Masters — настоящие лидеры, которые служат Scrum Team и всей организации.Scrum Master служит Scrum Team несколькими способами, в том числе: • коучит участников команды в части самоуправления и кросс-функциональности; • помогает Scrum Team фокусироваться на создании Increments с высокой ценностью, соответствующих определению готовности; • способствует устранению препятствий, мешающих прогрессу Scrum Team; а также, • убеждается в том, что все события Scrum происходят, позитивны, продуктивны и не выходят за рамки ограничений по времени.Scrum Master служит Product Owner несколькими способами, в том числе: • помогает находить техники эффективного определения Product Goal и управления Product Backlog; • помогает Scrum Team осознать необходимость четких и лаконичных элементов Product Backlog; • помогает применять эмпирическое планирование продукта в комплексной среде; а также, • фасилитирует взаимодействие с заинтересованными лицами по запросу или при необходимости.Scrum Master служит организации несколькими способами, в том числе: • направляет, обучает и коучит организацию в применении Scrum; • планирует переход на Scrum и консультирует по вопросам применения Scrum в рамках организации; • помогает сотрудникам и заинтересованным лицам понять и применять эмпирический подход к комплексной работе; а также, • устраняет барьеры между заинтересованными лицами и Scrum Teams Нет инструментов, которыми можно было бы провести измерение и дать простой точный ответ, насколько эффективен конкретный Scrum-мастер. Есть только некоторые индикаторы и косвенные признаки в работе команды, по которым можно примерно оценить, насколько в целом работа команды справляется с точки зрения процессов, и как следствие, насколько СМ справляется со своей ролью. За что отвечает Scrum-мастер? Согласно руководству, зону его ответственности можно разделить на три направления: способствовать возникновению в организации "среды Scrum" помогать Product Owner использовать эмпирический подход в потоке создания ценности, максимизировать эффект от усилий команды для продукта ответственность за обучение и работу Scrum-команды, за фокусировку её на правильных приоритетах Пункт 2 по сути можно разделить между первым и третьим пунктами. Часть функций SM здесь можно отнести к уровню всей организации (здесь уже корректнее говорить о Agile-трансформации всей системы), часть функций ближе к работе внутри Scrum-команды. Как убедиться, что в компании создана правильная среда Scrum? Можно проверить наличие обязательных артефактов Scrum, событий и каких-то доступных метрик — burn-down chart, cumulative flow diagram. Можно посмотреть, поставляет ли команда полезный заказчику инкремент в каждом Спринте, фиксируются ли улучшения на ретро и попадают ли они потом в бэклог. Все эти элементы можно увидеть, так что несложно составить некий чеклист и пройти по нему, отмечая по артефактам Да/Нет. Но едва ли такой чеклист покажет, насколько адаптивной является организация, использует ли она Scrum так, как задумано создателями подхода, или это всего лишь вариант Мрачного Скрама. Говоря о Scrum на уровне всей организации, речь уже фактически о трансформации организационной и управленческой структуры: организационный дизайн в виде продуктовых юнитов, в свою очередь спроектированных по принципу "от потребностей клиента к технологиям и процессам" переход от компонентных команд к кроссфункциональным фиче-командам все команды, работающие с одним продуктом, используют единый бэклог разделение продуктового менеджмента от линейного (задачи даёт только Product Owner) Однако редко такие преобразования в организации инициируют и драйвят Scrum-мастера. Почему это так — отдельный вопрос. Scrum-master в компании — довольно интересная роль. Это человек, важный в команде, по мнению авторов подхода; выполняющий сложную функцию, если он выполняет ее должным образом, как задумано. И при этом практически не обладающий никакими властными полномочиями. Но чтобы организация стала действительно адаптивной, недостаточно убедить всех, что дело это правильное, и организовать работу команд по Scrum. Нужно менять оргструктуру, а такой власти у SM нет. ”Попытки изменить организационную культуру наивны и всегда обречены на провал. Поведение людей (культура) всегда является продуктом системы. Изменение системы влечет за собой изменение поведения людей” (Джон Сэддон). На эту тему есть интересная статья у Василия Савунова (Agile тренер в ScrumTrek) —Эволюция Scrum-мастера. На начальных этапах работы, вероятно, лучше фокусировать внимание на оценке работы SM внутри команды. Это "операционка" Scrum-мастера. В основном эти обязанности и есть то, ради чего нанимают или назначают SM в команду. Помощь команде в построении такого рабочего процесса, который будет давать результат (ранняя проверка гипотез, инкремент каждый спринт, постоянное обучение) и будет устраивать команду и стейкхолдеров. Как все уже знают, в приказном порядке Scrum не построить — главный юнит фреймворка это сплоченная, мотивированная, самоогранизующаяся команда. Что значит: все участники понимают правила игры и принимают их. И здесь можно уже подумать о эффективности команды. Эффекти́вность — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015). То есть, грубо говоря, это соотношение между поставляемой заказчику ценностью (value) и стоимостью поставки. Стоимость при желании мы можем либо измерить, либо оценить. Более сложная штука — измерение поставленной ценности. Этот термин сам по себе достаточно нечеткий и каждый понимает под ним что-то своё. Но даже если мы сможем определить что есть поставленная ценность и измерить её, какой в этом вклад SM? На команду ведь всегда влияет множество факторов — изменения состава, краткосрочные отсутствия, отпуска, меняющиеся требования, сложность технической среды и т.п. Важный момент — прямая обязанность Scrum-мастера сделать все эти факторы максимально прозрачными. Все факторы должны быть видны и понятны как команде, так и всем заинтересованным сторонам. И это — главный критерий оценки. Можно определить некоторые косвенные "операционные" индикаторы, по которым есть смысл оценивать работу Scrum-мастера. Например: На каждом обзоре спринта у нас есть как минимум один стейкхолдер, который даёт обратную связь команде Команда поставляет готовый и полезный заказчику инкремент в производственную среду по завершении каждого спринта Когда возникает вопрос "Эта задача готова или нет?" можно обратится к Определению готовности (Definition of Done) и проверить соответствие Команда периодически проводит уточнение бэклога продукта, верхние элементы бэклога декомпозированы, описаны, оценены. В нижней части бэклога нет древних "покрытых пылью" элементов, которые лежат там уже месяцами или годами Оценка любого элемента бэклога не превышает среднее значение velocity команды, что означает — эту задачу можно сделать за спринт Так как подход Scrum это командный подход по определению, требующий полного вовлечения всей команды и открытых обсуждений, одна из важных компетенция Scrum-мастера — фасилитация. Умение организовать обсуждения таким образом, чтобы все могли высказаться, были услышаны и поняты, оставаясь при этом в рамках конструктива, сохраняя хорошие отношение и не тратя много времени на обсуждение не важных вопросов. В итоге обсуждения должно быть выработано решение, с которым все согласны и которое каждый участник воспринимает как своё. Обязанность SM здесь — стараться остаться самому и удерживать других в состоянии логичной оценки информации, взвешенных решений, принятии ответственности за свои решения. Отдельно стоит выделить проведение ретроспектив. Здесь основной фокус SM — не дать превратится этой встрече в приятное (или неприятное) времяпрепровождение, после которого ничего не следует в плане улучшений. В сети есть много материалов про антипаттерны ректроспектив, способы их проведения и вовлечения всей команды. Например здесь или здесь. Из этого следует еще один важный индикатор, показывающий что должное внимание уделяется архитектуре, решению важных технических вопросов — инфраструктурные изменения, работа с техдолгом. Здесь SM должен инициировать конструктивное обсуждение проблем на ретро, привести команду к пониманию важности постоянных улучшений, к необходимости фиксации улучшений и включения их в бэклог продукта. И отдельный важный момент — так как единственным владельцем бэклога в Scrum является Владелец Продукта, прямая обязанность SM — убедить PO в необходимости тратить часть усилий на "внутренние" технические задачи. Индикатором может служить наличие в бэклоге улучшений, вынесенных с ретро. Да, поиск и контроль этих индикаторов может быть не очень простой задачей, но оно стоит усилий. Ориентиром здесь могут служить принципы Scrum: прозрачность — то есть "причёсанный" бэклог, наличие понятных целей, критерия готовности, видимость всех артефактов и всех проблем для всех сторон процесса; инспекция — осмысленные и полезные всем встречи, вовлечение заинтересованных сторон; адаптация — получение и использование быстрой обратной связи, наличие полномочий у команды для принятия решений и их реализации. Project manager