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