О чем текст
Фреймворк Scrum, согласно исследованиям scrumtrek.ru, используют в работе более 50% организаций, работающих с Agile-подходами. На данный момент Scrum самый популярный подход, нравится вам это или нет. Можно пытаться бороться с ним, можно избегать, можно принять этот факт как данность и разобраться — возможна ли действительно эффективная работа в таком стиле, что нужно для этого делать, как проверять и корректировать свои действия? Роль Scrum-мастера ключевая в выстраивании рабочих процессов в команде, но при этом официальное руководство описывает что должен делать СМ, и ничего не говорит как именно нужно это делать. Можно ли вообще как-то измерить работу Scrum-мастера и понять, приносит ли он пользу команде и организации в целом, или это только "yet another role"?
На сегодняшний день самый популярный и распространённый метод гибкого (Agile) управления разработкой — Scrum. Одна из трех ролей в нём — 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-мастера:
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? Можно проверить наличие обязательных артефактов Scrum, событий и каких-то доступных метрик — burn-down chart, cumulative flow diagram. Можно посмотреть, поставляет ли команда полезный заказчику инкремент в каждом Спринте, фиксируются ли улучшения на ретро и попадают ли они потом в бэклог. Все эти элементы можно увидеть, так что несложно составить некий чеклист и пройти по нему, отмечая по артефактам Да/Нет. Но едва ли такой чеклист покажет, насколько адаптивной является организация, использует ли она Scrum так, как задумано создателями подхода, или это всего лишь вариант Мрачного Скрама.
Говоря о Scrum на уровне всей организации, речь уже фактически о трансформации организационной и управленческой структуры:
организационный дизайн в виде продуктовых юнитов, в свою очередь спроектированных по принципу "от потребностей клиента к технологиям и процессам"
переход от компонентных команд к кроссфункциональным фиче-командам
все команды, работающие с одним продуктом, используют единый бэклог
разделение продуктового менеджмента от линейного (задачи даёт только Product Owner)
Однако редко такие преобразования в организации инициируют и драйвят Scrum-мастера. Почему это так — отдельный вопрос.
Scrum-master в компании — довольно интересная роль. Это человек, важный в команде, по мнению авторов подхода; выполняющий сложную функцию, если он выполняет ее должным образом, как задумано. И при этом практически не обладающий никакими властными полномочиями. Но чтобы организация стала действительно адаптивной, недостаточно убедить всех, что дело это правильное, и организовать работу команд по Scrum. Нужно менять оргструктуру, а такой власти у SM нет.
”Попытки изменить организационную культуру наивны и всегда обречены на провал. Поведение людей (культура) всегда является продуктом системы. Изменение системы влечет за собой изменение поведения людей” (Джон Сэддон).
На эту тему есть интересная статья у Василия Савунова (Agile тренер в ScrumTrek) —Эволюция Scrum-мастера.
На начальных этапах работы, вероятно, лучше фокусировать внимание на оценке работы SM внутри команды.
Работа Scrum-команды
Это "операционка" Scrum-мастера. В основном эти обязанности и есть то, ради чего нанимают или назначают SM в команду. Помощь команде в построении такого рабочего процесса, который будет давать результат (ранняя проверка гипотез, инкремент каждый спринт, постоянное обучение) и будет устраивать команду и стейкхолдеров. Как все уже знают, в приказном порядке Scrum не построить — главный юнит фреймворка это сплоченная, мотивированная, самоогранизующаяся команда. Что значит: все участники понимают правила игры и принимают их.
И здесь можно уже подумать о эффективности команды. Эффекти́вность — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015). То есть, грубо говоря, это соотношение между поставляемой заказчику ценностью (value) и стоимостью поставки. Стоимость при желании мы можем либо измерить, либо оценить. Более сложная штука — измерение поставленной ценности. Этот термин сам по себе достаточно нечеткий и каждый понимает под ним что-то своё. Но даже если мы сможем определить что есть поставленная ценность и измерить её, какой в этом вклад SM? На команду ведь всегда влияет множество факторов — изменения состава, краткосрочные отсутствия, отпуска, меняющиеся требования, сложность технической среды и т.п.
Важный момент — прямая обязанность Scrum-мастера сделать все эти факторы максимально прозрачными. Все факторы должны быть видны и понятны как команде, так и всем заинтересованным сторонам. И это — главный критерий оценки.
Оценка эффективности
Можно определить некоторые косвенные "операционные" индикаторы, по которым есть смысл оценивать работу Scrum-мастера. Например:
На каждом обзоре спринта у нас есть как минимум один стейкхолдер, который даёт обратную связь команде
Команда поставляет готовый и полезный заказчику инкремент в производственную среду по завершении каждого спринта
Когда возникает вопрос "Эта задача готова или нет?" можно обратится к Определению готовности (Definition of Done) и проверить соответствие
Команда периодически проводит уточнение бэклога продукта, верхние элементы бэклога декомпозированы, описаны, оценены. В нижней части бэклога нет древних "покрытых пылью" элементов, которые лежат там уже месяцами или годами
Оценка любого элемента бэклога не превышает среднее значение velocity команды, что означает — эту задачу можно сделать за спринт
Так как подход Scrum это командный подход по определению, требующий полного вовлечения всей команды и открытых обсуждений, одна из важных компетенция Scrum-мастера — фасилитация. Умение организовать обсуждения таким образом, чтобы все могли высказаться, были услышаны и поняты, оставаясь при этом в рамках конструктива, сохраняя хорошие отношение и не тратя много времени на обсуждение не важных вопросов. В итоге обсуждения должно быть выработано решение, с которым все согласны и которое каждый участник воспринимает как своё. Обязанность SM здесь — стараться остаться самому и удерживать других в состоянии логичной оценки информации, взвешенных решений, принятии ответственности за свои решения.
Отдельно стоит выделить проведение ретроспектив. Здесь основной фокус SM — не дать превратится этой встрече в приятное (или неприятное) времяпрепровождение, после которого ничего не следует в плане улучшений. В сети есть много материалов про антипаттерны ректроспектив, способы их проведения и вовлечения всей команды. Например здесь или здесь.
Из этого следует еще один важный индикатор, показывающий что должное внимание уделяется архитектуре, решению важных технических вопросов — инфраструктурные изменения, работа с техдолгом. Здесь SM должен инициировать конструктивное обсуждение проблем на ретро, привести команду к пониманию важности постоянных улучшений, к необходимости фиксации улучшений и включения их в бэклог продукта. И отдельный важный момент — так как единственным владельцем бэклога в Scrum является Владелец Продукта, прямая обязанность SM — убедить PO в необходимости тратить часть усилий на "внутренние" технические задачи.
Индикатором может служить наличие в бэклоге улучшений, вынесенных с ретро.
Да, поиск и контроль этих индикаторов может быть не очень простой задачей, но оно стоит усилий. Ориентиром здесь могут служить принципы Scrum: прозрачность — то есть "причёсанный" бэклог, наличие понятных целей, критерия готовности, видимость всех артефактов и всех проблем для всех сторон процесса; инспекция — осмысленные и полезные всем встречи, вовлечение заинтересованных сторон; адаптация — получение и использование быстрой обратной связи, наличие полномочий у команды для принятия решений и их реализации.