Scrum Master. История роли. Часть 1: до Scrum Guide
В 2020-м году вышла новая версия Scrum Guide, которая изменила многое, в том числе и Scrum Master’а — теперь это даже не роль, а зона ответственности.
Многим в Agile-сообществе это показалось радикальным, но если посмотреть в историю вопроса, можно обнаружить, что ранее были гораздо более радикальные перемены в роли Scrum-мастера, на фоне которых Scrum Guide 2020 всего лишь сдувает пыль со старого описания. Давайте узнаем, какую трансформацию прошла роль Scrum Master прежде чем оказалась в 2020-м
Часть 1 | Часть 2
Не все в Agile-сообществе приняли изменения, озвученные в Scrum Guide 2020. Создатели LeSS, к примеру официально объявили, что игнорируют Scrum Guide 2020, и будут руководствоваться предыдущей версией Scrum Guide 2017.
А представьте как оно было ДО Scrum Guide? Scrum официально был представлен публике в 1995-м году, но 15 лет после этого, вплоть до 2010-го года не существовало какого-то единого руководства, к которому можно было бы апеллировать, чтобы сделать “правильный” Scrum.
Был ряд статей и книг по Scrum, каждая из которых что-то добавляла к общей картине, иногда противореча более ранней книге или статье.
Чувствуете, какая неразбериха творилась в головах у практиков Scrum в эти годы?
Драматических поворотов в истории эволюции роли Scrum Master’а с 1995 года по 2010-й там было предостаточно, и нынешние изменения в Scrum Guide 2020 — это во многом отголоски тех метаний, и поисков которые предпринимало сообщество в поисках правильной “формулы Scrum”.
Эта статья рассказывает об эволюции роли Scrum Master. Она состоит и двух частей:
- Первая часть рассказывает о нелегком становлении роли от момента появления Scrum, до появления первого Scrum Guide.
- Вторая часть будет посвящена пертрубациям роли Scrum Master в ревизиях Scrum Guide — с 2010 по 2020.
* я буду пользоваться двумя написаниями роли: «Scrum Master» и «ScrumMaster». Потому что с 1998го по 2011 й год роль называлась именно так — ScrumMaster ( слитно, как переменная в коде )
Часть 1. Scrum Master до Scrum Guide
Scrum Master не всегда был поддерживающим лидером, эти черты ему были приданы со временем, по мере накопления опыта работы по Scrum, и осознания необходимости передавать ответственность за решения самим сотрудникам, входящим в команду.
1995 — Первая публичная презентация Scrum
В которой роли Scrum Master еще нет
В Остине, штат Техас, Кен Швабер сделал доклад на конференции OOPSLA. Главной особенностью представленного подхода была идея объединить в Project Team выделенного представителя менеджмента (Management) и команду разработки (Development Team). Это было прорывное решение, так как сильно снижало вероятность ошибок и улучшало взаимодействие.
Но никакой роли ScrumMaster в тот момент предусмотрено не было.
1998 — Рождение ScrumMaster
Когда ScrumMaster — пока еще просто тимлид.
Первое упоминание роли ScrumMaster (да-да, именно вот так, слитно) было на страницах статьи “SCRUM: An extension pattern language for hyperproductive software development” (Mike Beedle, Martine Devos, Yonat Sharon, Jeff Sutherland and Ken Schwaber). На тот момент в Scrum были только 15-минутный Scrum Meeting, и встреча для Демонстрации результатов спринта.
Статья написана совершенно космическим языком, но именно в ней появляется роль ScrumMaster, которая описана как:
“…is a team leader role responsible for resolving the Blocks”
Перевод:
«…роль лидера группы (тимлида), ответственного за разрешение блокеров»
Прямо скажем, это мало чем отличается от обычного руководителя группы разработчиков (тимлида).
Что делал ScrumMaster в 1998 году:
- Выполнял функции тимлида
- Фиксировал задачи, блокеры и тд
- Нес ответственность за разрешение блокеров команды
По сути, ScrumMaster был эдаким секретарем команды, который фиксировал все проблемы, блокеры и задачи, которые возникают в процессе работы команды, с тем чтобы потом их разобрать, решить и спланировать.
На планировании спринта вместе с Архитектором ScrumMaster должен был помогать команде выбирать правильные задачи для спринта и фиксировать выбранные задачи в бэклоге. Как видим, он осуществлял еще и техническое руководство, определяя, что команде надо взять в работу.
2001. Книга Agile Software Development with Scrum
В которой ScrumMaster становится владельцем процесса, методологом и менеджером.
В 2001 году Кен Швабер и Майк Бидл опубликовали книгу «Agile Software Development with Scrum», которая оказалась поворотной вехой в истории Scrum. В этой книге детально описан Scrum-процесс, роли, артефакты, встречи, и принципы работы. Это было всеобъемлющее, подробное руководство о том, как правильно делать Scrum. В обиходе многие называли эту книгу “Scrum Book”, что само по себе о многом говорит.
По сравнению с версией 1998 года, роль ScrumMaster сильно меняется, и мера его ответственности значительно возрастает.
Если в 1998 году это был обычный тимлид, которому вменили в обязанность быть еще и секретарем команды, и разрешать Блокеры, то начиная с 2001 года на ScrumMaster возлагается вся ответственность за успех Scrum.
Буквально:
“The ScrumMaster is responsible for the success of Scrum […] The ScrumMaster is responsible for ensuring that Scrum values, practices and rules are enacted and enforced”. — Agile Software Development with Scrum
Перевод:
“ScrumMaster ответственнен за успех Scrum […] ScrumMaster ответственнен за обеспечение того, что ценности, практики и правила Scrum были введены в действие и выполнялись в полной мере.” — Agile Software Development with Scrum
Ответственность ScrumMaster’а была велика:
- Работает с клиентами и руководством, чтобы выбрать и назначить Владельца продукта;
- Управляет формированием состава Скрам-команды (найм, ассессмент);
- Работает с Владельцем Продукта для создания бэклога продукта;
- Работает со Скрам-командой над планированием спринта;
- Проводит Ежедневные Scrum-митинги;
- Отвечает за определение возможных препятствий, будучи активным слушателем Ежедневных Scrum-митингов и анализируя показатели скорости команды (velocity chart);
- Отвечает за устранение препятствий;
- Взаимодействует с руководством для улучшения процессов;
- Принимает решения. Может даже принять решение за всю команду.
По сути, ничто, связанное со Scrum, не могло произойти без согласия ScrumMaster.
ScrumMaster версии 2001 года “сидит на водительском сиденьи”, и управляет Scrum-процессом и Scrum-командой так же как водитель управляет автомобилем.
Причем, на роль ScrumMaster надо было поставить специально выделенного человека с широкими административными полномочиями. Книга явно указывает нам, что на эту роль должен быть назначен кто-то из перечисленных: Team Leader, Project Leader, Project Manager.
Если попытаться подытожить, кем был ScrumMaster в книге 2001 года, то правильно будет сказать, что он был владельцем процесса, методологом, и менеджером.
Интересно, что в Scrum Guide 2020, спустя 19 лет, тоже появилась похожие формулировки:
“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization” — Scrum Guide 2020
Перевод:
“Scrum Master’а ответственны [перед командой] за то, чтобы установить такой Scrum-процесс, как определено в Scrum Guide. Они делают это, помогая всем понять теорию и практику Scrum, как на уровне команды, так и на уровне организации” — Scrum Guide 2020
Но есть разница. В 1998 году для описания образа действий ScrumMaster используется слово “enforce” — буквально “принуждать”.
А в 2020-м в ход идут слова “coaching”(коучинг) и “helping”(помогать) и другие слова, которые указывают на поддерживающее поведение.
Гуманизация роли за 19 лет налицо 🙂
Мне кажется, что такое определение роли ScrumMaster было связано с тем, что в 2001 году мало кто знал что такое Scrum, и это была прям такая экзотика с точки зрения привычного менеджмента, что внедрять его можно было только директивно, имея полномочия и власть. Иначе он просто не “заводился” и его отторгали. И конечно, нужен был какой-то эксперт, который бы наладил все как надо, не допуская отклонений и искажений идеи.
Позже, знания о практике применения Scrum распространились очень широко, и нужда в эдаком “супермене” от Scrum, отпала. Часть инструментов стала обычным делом, и поэтому ответственность постепенно передавалась в команду.
2003. Статья “What is Scrum”
В которой ScrumMaster превращается в ”улучшатора” команды
Спустя 2 года после выхода книги, Кен Швабер написал статью про Scrum.
Что интересно в ней, так это то, как поменялось описание роли ScrumMaster:
“The ScrumMaster is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so it fits within an organization’s culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices.” — What is Scrum, Ken Schwaber 2003
Перевод:
“ScrumMaster ответственнен за Scrum-процесс, за обучение этому процессу всех вовлеченных в проект [сотрудников], за реализацию [Scrum] таким образом, чтоб он вписывался в культуру компании и в то же время предоставлял ожидаемые выгоды от него, а так же он отвечает за то, чтобы все [сотрудники} следовали правилам и практикам Scrum.” — What is Scrum, Ken Schwaber 2003
И все.
Сравните это с длиннющим перечнем обязанностей из основополагающей книги “Agile Software Development with Scrum” 2001-го года.
Удивительно, но всего через два года после выхода этой книги, авторы подхода освобождают ScrumMaster от множества обязанностей. В частности, от обязанности вместе с Владельцем Продукта формировать бэклог. Теперь не ScrumMaster, а Команда разработки определяла наилучший способ превращения элементов бэклога в ценный Инкремент продукта. За ScrumMaster осталась ответственность за Scrum-процесс и его эффективность, а также за обучение участников команды.
Стоит отметить, что именно в этой статье впервые в Scrum-процесс вводится новая встреча — Ретроспектива. До 2003 года ее в Scrum не было. Естественно, что ответственность за проведение Ретроспективы целиком и полностью ложится на ScrumMaster.
То есть, ScrumMaster становится больше поддерживающим лидером, можно сказать “улучшатором” команды.
Своей статьей Кен Швабер с одной стороны, пролил свет на многие нюансы реализации Scrum, и скорректировал зону ответственности Scrum Мастера, но в то же время он внес большую путаницу, так как основным источником истины оставалась книга 2001-го года “Agile Software Development with Scrum”.
Так бы оно все, наверно и продолжалось, но в 2002-м году был создан Scrum Alliance и первая программа сертификации ScrumMaster (Certified ScrumMaster — CSM). Так что с путаницей надо было наводить порядок, и в 2004-м году выходит книга Кена Швабера “Agile Project Management With Scrum” (русский перевод https://www.alpinabook.ru/catalog/book-571957/ )
2004. Agile Project Management With Scrum
В которой ScrumMaster становится фасилитатором
После создания ScrumAlliance и запуска первой сертификации “Certified ScrumMaster”, Кен Швабер написал вторую основополагающую книгу по Scrum. Теперь надо было на примерах и кейсах объяснять практику работы по Scrum.
Книга сугубо практическая, со множеством примеров и кейсов, на основе которых разбирается Scrum-мероприятия, роли и артефакты.
При описании роли ScrumMaster много внимания уделяется различиям роли ScrumMaster от обычного Project Manager. Эти различия разбираются на примере множества конкретных ситуаций, когда ScrumMaster ведет себя как классический проектный менеджер, и что из этого получается.
Главный вывод книги о роли ScrumMaster в том, что его авторитет держится не на власти и формальных полномочиях, а на глубокой экспертизе в Scrum и понимании философии Scrum.
ScrumMaster в книге Кена Швабера, это сильный и опытный фасилитатор, который помогает команде самостоятельно решать свои проблемы, договариваться между собой и принимать решения по важным вопросам.
“The authority of the ScrumMaster is largely indirect; it springs mainly from the ScrumMaster’s knowledge of Scrum rules and practices and his or her work to ensure that they are followed. The ScrumMaster is responsible for the success of the project, and he or she helps increase the probability of success by helping the Product Owner select the most valuable Product Backlog and by helping the Team turn that backlog into functionality. The ScrumMaster earns no awards or medals because the ScrumMaster is only a facilitator” — Agile Project Management With Scrum, 2004
Перевод:
“Авторитет ScrumMaster’а в значительной степени косвенный; он зиждется на знаниях ScrumMaster’а о правилах и практиках Scrum, и на его или ее работе, направленной на обеспечение их выполнения. ScrumMaster ответственнен за успех проекта и помогает увеличивать вероятность успеха, помогая Владельцу Продукта выбрать наиболее ценностные [элементы] Бэклога Продукта и помогая Команде превратить этот Бэклог в функционал [который работает]. ScrumMaster не получает наград и медалей, потому что ScrumMaster всего лишь фасилитатор. — Agile Project Management With Scrum, 2004
Роль ScrumMaster все дальше отходит от того директивного Scrum-менеджера, который описан в книге 2001-го года. Все больше полномочий и ответственности передается в команду, и на Владельца продукта.
В то же время, ScrumMaster несет личную ответственность перед командой за то, чтобы выстроить рабочий процесс Scrum максимально эффективно, глубоко вовлекаться в проблемы команд, поддерживать и помогать ей в трудные моменты.
Как пишет Кен Швабер:
“ScrumMasters have to make a personal commitment to their teams. A ScrumMaster would no more delegate his responsibilities than a sheepdog would lie down for a nap while herding the flock. The team needs to sense that someone is deeply invested in its work and will protect and help it no matter what” — Agile Project Management With Scrum, 2004
Перевод:
“ScrumMasters должны брать на себя личные обязательства перед своими командами. ScrumMaster может делегировать свою ответственность не больше чем это может сделать пастушья собака, которой вдруг захочется вздремнуть, в то время как она пасет стадо. Команде нужно чувствовать, что есть кто-то, кто глубоко вовлечен в ее работу и будет защищать и помогать ей, несмотря ни на что.” — Agile Project Management With Scrum, 2004
2009. Succeeding with Agile.
В которой наконец-то, ScrumMaster становится Servant Leader
Майк Кон написал прекрасную книгу “Succeeding with Agile”, в которой очень подробно, понятно и полно описал процесс адаптации сотрудников и организации к использованию Scrum и описал множество нюансов которые надо предусмотреть до запуска работ по Scrum, и в процессе работы.
В числе прочего, он весьма подробно разбирает роль ScrumMaster. В этой книге, впервые, насколько мне известно, ScrumMaster называют Servant Leader (Служащий Лидер). До этого такой концепции не озвучивалось.
Майк Кон предлагает смотреть на ScrumMaster как на персонального фитнесс-тренера, который помогает вам придерживаться правильного режима тренировок, и делать все упражнения правильно. Он будет вас мотивировать и поощрять, но у него нет прямой власти над вами, он не может заставить вас сделать упражнение, если вы этого не захотите. Вместо этого он будет апеллировать к вашим целям, и что вы сами выбрали для их достижения данный курс тренировок.
Точно так же и ScrumMaster. Он не может давать прямые указания участникам команды, что и как делать, для достижения целей спринта, но может изменить рабочий процесс, или план мероприятия так, чтобы команда начала вести себя более эффективно, достигая своих целей.
Подобно тому, как клиент дает персональному тренеру права на управление процессом тренировок, ScrumMaster права на управление рабочим процессом дает команда, без согласия которой никакие изменения невозможны.
Поэтому ScrumMaster действует не директивно, а с помощью коучингового подхода и фасилитации. Помогает команде обсудить и понять, какие именно изменения рабочего процесса повысят эффективность и решат проблемы. Принимать решение об изменениях рабочего процесса, которые могут повлиять на результат спринта, может только команда. ScrumMaster лишь помогает ей увидеть проблему, и придумать решение.
Майк Кон выделяет шесть атрибутов хорошего ScrumMaster:
- Ответственность (Responsible)
- Скромность (Humble)
- Сотрудничество (Collaborative)
- Преданный идее (Committed)
- Влиятельный (Influential)
- Знающий (Knowledgeable)
Картинка ScrumMaster, нарисованная Майком Коном, показывает нам очень опытного, зрелого, знающего эксперта, который мастерски владеет навыками фасилитации и коучинга, и умеет управлять командой, без давления, на основе общения, вопросов, разбора ситуации и в конечном итоге, осознания командой, какие проблемы перед ней стоят, и как их лучше решать.
Конец первой части
Почему команды так не любят изменения? Как это проявляется и почему на самом деле сопротивление — это хороший знак? В этой статье обсудим, какую роль играет сопротивление и как Agile-коуч может не бороться с ним, а использовать в интересах команды, применяя различные техники.
Что такое интервизия и действительно ли она помогает скрам-мастерам и agile-коучам, как правильно организовать такую встречу и зачем интервизия нужна самой компании. В статье я постараюсь ответить на все эти вопросы и рассказать о своем опыте, а в конце поделюсь кратким чек-листом для участников, которые хотят извлечь из интервизии максимум пользы.
Современные компании сталкиваются с необходимостью постоянных изменений — будь то адаптация к новым рыночным условиям или улучшение внутренних процессов. Как найти способ эффективно внедрять изменения, причем так, чтобы сделать это быстро и с минимальным сопротивлением от команды? Один из инструментов, который может помочь в этом, — HADI-цикл.