Статья подготовлена Дмитрием Емельяновым в преддверии старта курса "Agile Project Manager".
Я почитал несколько статей про Agile, Scrum, Скрам мастеров и других, которые публикуются здесь, на Хабре. Они могут встретить разную реакцию, но есть достаточно четкая параллель между степенью восторженности в посте и градусом в комментариях, поэтому давайте попробуем без лишних розовых очков пройтись по роли Скрам мастер. Я попытался собрать самые интересные мнения на Хабре на этот счет и немного их раскрутить, вот что получилось:
Вообще не понимаю, кто это и зачем.
Скрам бесполезен, Скрам-мастер соответственно тоже.
Скрам мастер не нужен, в виде отдельного человека уж точно.
Полную занятость он, конечно, оправдывает, только если шэрится на много команд.
Давайте по порядку.
Вообще не понимаю, кто это и зачем
В последнее время в своей профессиональной жизни, когда передо мной стоит задача объяснить, как работает Скрам, то чаще всего я имею дело с ИТ-специалистами, которые либо уже имели опыт работы в Agile командах, либо, как минимум, слышали об этом. Но это мой local bubble — в действительности же очень много профессионалов не слышали об этом ровным счетом ничего. Если в двух словах, то: Скрам мастер — менеджер процесса в Скраме. А Скрам, в свою очередь — это подход к работе команды.
Если вы никогда не слышали ни о том, ни о другом, то это значит, что вы работаете в другом организационном контексте. Очень может быть, что именно вы и не будете с этим сталкиваться, ну и не надо соответственно загружать этим голову.
Скрам — весьма хороший инструмент, но он узкопрофильный. Это как иметь отдельную отвертку для труднодоступных мест, она редко когда нужна — но когда нужна, то просто спасает вас. В этом и ключевая идея Скрама — он показывает свою максимальную эффективность, когда перед организацией стоит задача эффективного создания или развития продукта. При этом в развитии продукта должен стоять фокус на реализации самого ценного. В других ситуациях Скрам будет не лучшим инструментом, хоть и пригодным. Итого:
В любой организации развитие продукта — это лишь его малая часть, для функционирования любого продукта нужно много разных сервисов. Скрам закрывает только развитие.
Продуктовые компании — это лишь малая доля от общего числа компаний. Некоторые пытаются ими стать, некоторые не пытаются и им это не нужно.
Если вы не знаете, что такое Скрам, Скрам мастер и по работе вы с этим и не сталкиваетесь, то оно вам и не нужно.
Скрам — узко специализированный фреймворк, спроектированный под цель максимизации ценности. Если в организации другой фокус, то оно вам и не нужно.
Скрам мастер выстраивает Скрам процесс, он в нем эксперт.
Скрам бесполезен, Скрам-мастер соответственно тоже
Всякий раз, когда я сажусь писать про роль Скрам мастера, которая мне близка и симпатична, то она все равно уходит в обсуждение Скрама. Так уж получилось, эти темы действительно идут рука об руку.
Эмоции в этой фразе понятны, давайте подумаем, что их вызвало. По опыту, самый частый аргумент у человека, который дает такую оценку — это про «кучу бесполезных встреч в Скраме». Давайте разберемся, дайте мне пару минут позанудствовать.
Чисто технически, в Скраме 4 встречи, которые называются события, но в контексте нашей статьи это значения не имеет. Также есть часто встречающаяся практика, когда груминг бэклога делают отдельной встречей, итого 5. У них разная периодичность — какие-то встречи ежедневные, какие-то проводятся раз в спринт. Предположу, что дело не в количествах встреч, а в их качестве. Качество встречи определяется такими факторами, как: цель встречи, повестка встречи, результат на выходе, а также правил, которым мы придерживаемся во время встречи, для того чтобы достигнуть цель и получить результат на выходе. В Скрам гайде цели и ожидаемые результаты от каждой встречи зафиксированы, они конкретны, а способ достижения этих целей остается за командой. По моему опыту, здесь обычно собака зарыта — любую встречу можно свести до неэффективной. Давайте пройдемся по ключевым анти-паттернам.
1. Стендап (который называется Daily Scrum)
Ежедневная встреча, которая обычно длится 15 минут и меньше, служит для того, чтобы понять, где команда находится относительно достижения цели спринта. Обычно обсуждают, что сделано, что будут делать и какие есть трудности, но это лишь один из форматов проведения. Частые проблемы этой встречи: значительно затягивается (встречал ситуацию, где стендапы были по 1,5 часа), превращается в отчетную встречу перед продактом или каким-либо руководителем. Если вы узнали какой-то из примеров в своем, то дело не в Скраме, а в том, как вы его реализуете.
2. Планирование спринта
Встреча, которая происходит раз в спринт, обычно в начале, где команда определяет для себя план. План состоит из ответа на три вопроса: зачем, что и как. Фактически команда выносит с планирования цель спринта, спринт бэклог (план по достижению цели) и понимание, как именно они будут достигать цель. Это, действительно, обычно длинная и достаточно сложная встреча для команды, поскольку планирование на спринт происходит с высокой степени детализации, к которому обычно люди не привыкли. На моей практике планирование обычно вызывает меньше недовольства со стороны ИТ-специалистов, потому что ее смысл прямо следует из названия. Больше недовольства тут концентрируется на том, как оно проходит и на реалистичности построенных планов. И вот тут как раз Скрам мастер решает эту задачу — он проводит встречу (грамотнее сказать — фасилитирует, но статья не об этом) и помогает ее сделать эффективной, получающийся результат со встречи делать ценным для бизнеса, а планы реалистичными и реализуемыми за спринт. Также помимо проведения самой встречи к ней необходима качественная проработка, которую делает Скрам мастер с Владельцем продукта, это тоже значимо влияет на качество планирования.
3. Обзор спринта
Обычно называется демонстрацией в разных компаниях и воспринимается отчетной встречей. В действительности в это событие был заложен немного другой смысл. Помимо непосредственной демонстрации результата, это еще точка взаимодействия со стейкхолдерами, которая позволяет поддерживать прозрачность не только результатов работ, но и планов на будущее, а также текущей ситуации в продукте в целом. Опять же, Скрам мастер помогает ее сделать полезной всем участникам — команде, Владельцу продукта и стейкхолдерам.
4. Ретроспектива
Встреча команды с Продактом, где они имеют возможность остановиться и посмотреть системно на процесс работы в целом и попробовать его улучшить. Частое недовольство, которое касается ретроспектив — это обсуждение проблем без непосредственной реализации идей, которые на ней поднимаются, а также поднятие вопросов, которые могут находиться вне зоны влияния команды. И то и другое — ответственность Скрам мастера. Любой человек очень быстро поймет бесполезность обсуждения без последующей реализации — Скрам мастер владеет техниками, которые позволяют в дальнейшем реализовать задумки команды по процессу, например, положить также их в бэклог будущих спринтов, а какие-то инициативы реализовать самостоятельно в организации. Системные изменения — это то, зачем нужен Скрам мастер — не только проводить встречи. В редких ситуациях встречается, когда команда от решения системных проблем переходит к поиску виновных и ретро может стать весьма эмоциональным — но цель встречи другая, и помочь сфокусироваться именно на пользе от нее — это тоже работа Скрам мастера.
Думаю, что ключевая мысль в бесполезности встреч кроется не в их количестве, а все-таки в их качестве. Эффективность встреч — это прямая ответственность Скрам мастера, но не единственная.
Скрам мастер не нужен, в виде отдельного человека уж точно
Вот тут я буду краток. В моем опыте я работал с разными Скрам мастерами, которые работали part-time и full-time. Здесь нет абсолютной истины в этом вопросе, так как Скрам гайд оперирует термином роль, а не должность.
На практике, когда человек совмещает в себе две роли — например, разработчик и Скрам мастер или аналитик и Скрам мастер, то функционал Скрам мастера сужается до эффективного проведения встреч. В случае когда это отдельная должность в организации, то его функционал шире, включает в себя устранение препятствий работе команды. Оба случая приносят свою пользу и являются производной от текущего организационного контекста.
Я в своем опыте больше работал как full-time Скрам мастер и работаю с такими специалистами сейчас, но мой опыт касается малого количества организаций, которые претерпевали изменения.
Полную занятость он оправдывает, только если шэрится на много команд
Кстати, тоже практика, которая часто встречается в организациях. Скрам мастера, с которыми я работаю, чаще всего работают с 1-2 командами, которые находятся в едином контексте бизнеса. Например, Скрам мастер, который работает с двумя командами в рамках бизнеса, например, потребительское кредитование.
На мой субъективный взгляд, что это максимум для одного специалиста — все дело как раз таки в том, что помимо эффективных встреч, у Скрам мастера стоит задача построения Скрам процесса в целом, а для этого нужно решить много организационных сложностей, которые и съедают большое количество сил и времени, так как организационные препятствия работы команды редко решаются легко, быстро и с первого раза.
Тем не менее, я встречаю на рынке Скрам мастеров, которые работают с 3 командами и более, обычно их фокус работы немного другой — больше фокус на поддержке процесса, чем на инициации изменений.
Давайте я попробую подвести небольшой итог тому, что я хотел сказать, изложив суть кратко.
Скрам мастер — это роль, которая управляет Скрам процессом. Встречи в рамках процесса — это очень важная задача, но не единственная. В своей работе команда встречает много сложностей, и задача Скрам мастера их устранять. Например:
Продакт не приоритезирует задачи, команда не может выстроить процесс работы со внешней системой, огромное количество багов на тестировании, отсутствие каналов для получения обратной связи по продукту, регулярное невыполнение планов на спринт, отсутствие необходимой экспертизы у команды, внутренние и внешние конфликты команды, отсутствие прозрачности в процессе работы, много разных источников задач и многие другие. Это то, что может и должен решать Скрам мастер, разобраться в корневой причине и помочь выбрать инструмент, который решает это. Про эту важную часть почему-то забывают.
Если вы посмотрите резюме хорошего Скрам мастера, то там будет сказано не о том, как он хорошо поддерживал процесс, а про те изменения, которые он сделал в процессе работы команды и иногда организации в целом. Средства реализации этого остаются за самим профессионалом, стили работы разных людей различаются, иногда разительно.
Сегодня в 20:00 состоится открытое занятие «Техники оценки Agile проектов для различных контекстов». На нем разберём виды оценок проектов и задач в зависимости от срочности, размера и сложности объёма работ. Научимся выбирать к ситуации и применять «размеры футболок», человеко-часы, story points, PERT и несколько других способов. А также коснёмся классического инструмента critical path. Регистрация доступна по ссылке.