Привет! Меня зовут Маша Резниченко, и я работаю Agile-коучем в Страховом Доме ВСК. До этого 4 года я была скрам-мастером, и за это время сталкивалась с разными мнениями о моей профессии: от сомнений в её необходимости до откровенных насмешек и язвительных комментариев о том, что скрам-мастера — это «паразиты» в мире IT. 

Конечно, такие слова задевают. Ведь скрам-мастера — это агенты изменений, которые помогают командам и компаниям внедрять культуру Agile и Scrum. Их влияние выходит далеко за рамки проведения встреч или составления графиков. На Хабре можно найти множество обсуждений на эту тему, и я решила внести свой вклад, развенчав популярные мифы о скрам-мастерах. 

Скрам-мастер — это человек, который является экспертом по фраемворку Scrum, что видно из названия, и его главная задача — обучить сотрудников всем необходимым навыкам, которые позволят коллективу стать настоящей командой, а именно:

• самоорганизованной — той, что не нуждается в надзирателе для контроля сроков. Она принимает решения в рамках поставленных целей без прямого внешнего управления, т.е. это про свободу выбора методов и способов достижения заданных целей,

• самоуправляемой — это про контроль над всей деятельностью команды, распределение задачи и нагрузку включая постановку целей,

• обученной знаниям фраемворка — не только знает теорию Scrum, но и умеет применять её на практике.

По сути, скрам-мастер помогает командам стать автономными, оставаясь в рамках фреймворка. 

Два слова: люди и процессы.

В теории звучит просто, а на практике сталкиваемся с тем, чем действительно сложно работать — с человеческим фактором. Все команды разные, участники приходят со своими убеждениями, со своими тараканами (киньте в меня камень, кто живет без них в голове) и со своей призмой опыта и взглядов. В этом скрывается неочевидная для других участников команды проблема. Скрам-мастера работают в первую очередь с людьми, во вторую очередь с процессами. Грубо говоря, мы являемся «психологической» подушкой и поддержкой команды и при этом так же являемся «менеджерами» процессов.

Под процессами я имею ввиду абсолютно любые, которые есть в команде:

• релизный процесс,

• процесс решения конфликтов,

• процесс взаимодействия внутри команды,

• процесс взаимодействия команды с внешним миром.

Даже в процессе передачи задачи между ролями есть проблемы! Часто в командах сталкиваюсь с невыполнением планов из-за банального недопонимания в разграничении между ролями: разработчик может понять задачу по-своему, не уточнив у аналитика требования или конечный результат. Далее страдает тестировщик, т.к. видит несоответствие ожидания-реализации постановки, а все это приводит к задержкам выпуска релиза.

И если конкретно у вас в команде с этим все хорошо, то это не значит, что у всех других точно так же. Скорее всего, кто-то из вашей команды когда-то взял ситуацию в свои руки, проанализировал проблемы, предложил решения и воплотил их в жизнь. Но сколько времени и сил было потрачено на это? Сколько сопротивления он встретил вместо того, чтобы заниматься своей прямой работой — писать код? 

Хочется сравнить скрам-мастера с психологом: часто мы слышим «Мы и без вас разберёмся!» Конечно, разберётесь. Но самостоятельная работа займёт больше времени и сил, а скрам-мастер поможет сделать это быстрее и эффективнее. 

Еще один часто встречающийся вопрос: может ли команда обойтись без скрам-мастера? Отвечу таким сравнением: может ли человек выучить язык самостоятельно? Однозначно да! Он может тратить месяцы и годы на самостоятельный поиск ресурсов, литературы, видео уроков, а может нанять репетитора, который даст структуру и научит системности подхода. Вопрос в том, насколько важно и нужно вам дополнительное вмешательство, которое явно облегчит путь и ускорит появление результатов. Так же и с необходимостью срам-мастера в команде.

Когда компания входит в Agile трансформацию, не обойтись без помощников — агентов изменений (они же скрам-мастера). Именно они помогают внедрять культуру того самого Agile и Scrum в компанию.

Теперь перейдём к самым распространённым мифам о Scrum и скрам-мастерах. 

Миф: Scrum нужен только для контроля менеджеров

Опровержение: Scrum создан для повышения прозрачности и самоорганизации команды, а не для усиления контроля. Коротко сошлюсь на то, из чего скрам сделан: в основе лежит всем известный цикл PDCA:

Plan — Do — Check — Act

Адаптированный для работы в командах через введение специальных мероприятий, отражающих этапы:

Планирование — Реализация в ходе спринта — Ревью спринта — Ретроспектива спринта

В Agile мире используются помогающие метрики, одной из которых является BurnDown Chart.  График работоспособности — это инструмент для команды, используемый для отслеживания прогресса. Точно не для менеджера, чтобы "гадать на кофейной гуще". Контроль в Agile среде заменяется доверием и открытой коммуникацией, которые настраивает скрам-индивидуальности каждой команд.

Подробнее о командной зрелости, как её померить, как Scrum-мастеру вести себя на каждом уровне развития команды и что мешает прийти к этой самой зрелости, а также что делать Scrum-мастеру прямо сейчас, чтобы приблизить свою команду к зрелости – обсудили на подкасте Дневник Айтишника.

И подчеркну: задача скрам-мастера создать благоприятную среду в команде, в которой будет возможно реализовывать самые смелые идеи, в границах разумного, без страха осуждения. Фраемворк нацелен на разделение ответственности между ролями и передачи контроля и ответственности каждой: Product Owner за бизнес ценность конечного функционала, команда за качественную реализацию, а скрам-мастер за процессы в команде.

Предложу свою метафору: Product Owner — это композитор, который тщательно продумывает, какая музыка будет резонировать с публикой, создавая партитуру на основе её предпочтений. Команда — это оркестр, воплощающий эти замыслы в жизнь, превращая идеи в мелодию. А скрам-мастер — дирижёр, который не играет сам, но помогает каждому музыканту внести свой вклад, раскрывая общий потенциал команды, и направляет их так, чтобы все звучали в унисон, превращая замысел в идеальное исполнение.

Миф: Scrum превращает каждую задачу в бесконечный созвон

Опровержение: Scrum ограничивается четырьмя обязательными встречами в спринте и одной короткой ежедневно. Их цель — минимизировать дополнительные собрания и обеспечить продуктивную коммуникацию. Если созвоны занимают всё время, проблема, вероятно, не в Scrum, а в отсутствии фокуса на его базовых принципах.

Scrum — это описание инструментов, ролей, артефактов и принципов, которые адаптируются под любой контекст, если он включен в ситуации, в которых scrum уместен.

Чтобы определить стоит ли в вашем контексте использовать scrum поможет модель Киневина:

Однако, стоит помнить, что это легковесный фреймворк, который не дает ответы на все вопросы, но есть его принципы и ценности, опираясь на которые вы сможете принять верное решение. Сложен в понимании, легок в использовании.

В любой непонятной ситуации спросите себя: а как предложенное решение коррелирует с ценностями? Если ответ никак или противоречит, то ищем другое решение, приносящее настоящую значимость и ценность.

Миф: Планирование спринта — это трата времени

Опровержение: Планирование спринта — это не постановка жёстких дедлайнов, а обсуждение реального объема работы, который команда может взять. Цель — обеспечить прозрачность, а не создать чувство вины. Эффективное планирование занимает всего несколько часов, а не дни. Опять же, если в команде есть хороший скрам-мастер, он не позволит тратить бесценное время впустую (касается и предыдущего пункта тоже).

Заблуждение считать, что в Agile или Scrum нет сроков и дедлайнов. Первое — это философия и образ мышления, в центр которого ставится клиент и закрытие его потребностей так, чтобы по результату выпуска функционала он был актуален и приносил ожидаемую бизнес ценность.

Сроки и дедлайны — это ожидания готовой функциональности. Чтобы не быть заложником костылей и багов нужно выделить время на осознание и принятия того, откуда появляются срезанные углы и баги. На мой взгляд, без углубления в контекст, это признаки хромающего планирования и возможно низкой экспертизы в оценке задач. Когда команда знает свою емкость на спринт и задачи оценены корректно, ей намного проще управлять и составлять себе план и давать прогнозы того, что команда реально в состоянии выполнить. И ответственность за объем реализуемого ложится на команду, а не на внешних людей.  Исключим ситуацию, когда начальство давит, впихивает непомерные задачи и сама рисует дедлайны. В таком случае это не scrum, а его антагонист.

Миф: Ретроспектива — это способ обвинить разработчиков

Опровержение: Ретроспектива — это инструмент командного роста. Здесь не ищут виноватых, а совместно анализируют, как улучшить процессы. Успешные команды используют ретроспективы для усиления взаимопонимания и генерации новых идей. Возвращаемся к признанному циклу PDCA или к научному подходу, где финальным этапом цикла является рефлексия, осознание ошибок и корректировка дальнейших процессов, чтобы избежать прожитых ошибок и вытоптать новую тропинку. Не могу не упомянуть фразу: глупо рассчитать на иной результат, если действия по достижению результата не меняются. Всем нужно время чтобы замедлиться и проанализировать прошлый результат, для того чтобы понять, что нужно изменить чтобы прийти к лучшему результату.

А команда действительно ответственна за процессы, которые в ней происходят. Если есть проблемы — о них нужно говорить! Но чтобы перейти к открытым разговорам, необходимо доверие, которое скрам-мастер и помогает создавать.

Кстати, в жизни я рекомендую использовать ретроспективу для того, чтобы оценивать свои результаты и дальнейшие шаги. Как пример: человек ходит в спортивный зал, чтобы сбросить вес и стать выносливее. Первые результаты обычно случаются в первые месяцы, затем результаты становятся менее заметными и кажется, что ничего не меняется и началась стагнация или вес действительно перестал уходить, а ягодицы все еще не приблизились к заветному округлению.

Что происходит тогда? С грамотным тренером вы проведете рефлексию, проверите питание, результаты и поменяете стратегию (опять возвращаемся к PDCA) и продолжите тренировки, но уже с корректировкой. Результат не заставит себя долго ждать. Однако, если пренебрегать изменениями процесса, то и желаемый результат может не случится, и вместо него придет разочарование в тренировках и закрепление мысли «не быть мне стройным человеком».

Миф: Scrum Master — это ненужная роль

Опровержение: Скрам-мастер обеспечивает работу всей команды, устраняя препятствия, улучшая взаимодействие и обучая Agile-принципам. Это профессиональная роль, требующая компетенций в коучинге, фасилитации и лидерстве. Как говорила в начале статьи, скрам-мастер — это сочетание знаний и умений не только в построении процессов, но и работе с людьми, соответственно, багаж опыта включает огромное количество аспектов. Проведение встреч (фасилитация) — звучит просто: собрали людей, поговорили, быстро решили проблемы и пошли работать. А много ли на вашем опыте действительно качественных встреч, после которых появились решения, да не абы какие, а дающие реальную пользу и прогресс? И которые не затягивается на долгие часы, а то и месяцы в ожидании. Зовете ли вы туда всех подряд и игнорируете ли присутствие по-настоящему ключевых участников?

А есть ли у вас цель встречи? А насколько она достижимая в рамках встречи? Кстати, цель «Обсудить проблему» — целью не является, а звучит скорее, как потраченное зря время.

Составляете ли вы план встречи? Готовите ли фактуру? Такие вещи, кажущиеся на первый взгляд элементарными — провести встречу (да что там сложного!) требуют качественной подготовки и владением определенными знаниями и навыками, чтобы действительно соответствовать ожиданиям.

К сожалению, наша работа выглядит как работа серого кардинала, ее не видно и тяжело осязать в моменте, но если сравнить «до» и «после» работы скрам-мастера в команде, то результат вас точно удивит!

Миф: Спринты и сторипойнты вызывают шизофрению

Опровержение: Сторипойнты — это инструмент оценки сложности задач, а не их продолжительности. Их цель — помочь команде планировать. Если задачи остаются незавершёнными, это сигнал к анализу на ретроспективе, а не повод отказываться от спринтов. Мне больно читать как люди готовы отказаться от действительно ценных инструментов только лишь потому, что у них не получилось их использовать по назначению.

Когда мы говорим об оценке задач и планировании, то в первую очередь сторипоинты — это инструмент, помогающий оценить задачи команды относительно друг друга, исключая привязку к человеко-часам, тем самым создавая уникальную шкалу оценки, которая будет работать даже если часть команды сменится. На самом планировании рассчитывается емкость, которой располагает команда, чтобы дать правильный прогноз для заказчиков и Product owner. А спринты — это не магическое нечто, а временное ограничение, чтобы успеть выпустить готовый и ценный для пользователя функционал. Если что-то идет не так, то это просто необходимо проанализировать на ретроспективе, чтобы действовать по-другому и получить другой результат.

Миф: Стендапы — это пустая формальность

Опровержение: Стендап — это возможность синхронизации команды. Если он превращается в формальность, проблема в реализации, а не в подходе. Скрам-мастер может помочь сделать встречу более осмысленной. «А давайте сделаем Дейли 1-2 раза в неделю» — это следующее, что команда хочет сократить после ретроспектив, не умея их использовать себе во благо.

Кстати, все церемонии изначально созданы с благими намерениями для команды (и снова PDCA: выкинешь из него элемент и о пользе всего цикла можно забыть) и, если пользы от них вы не получаете — постарайтесь определить, что именно вам не нравится, и как настроить процесс под контекст и особенности вашей команды. Scrum не говорит бездумно внедрять все элементы в жизнь команды, Делайте поступательно и осознано. Начните с простого разрешения себе и остальным участникам команды просто попробовать и пощупать каждую церемонию. Поговорите со срам-мастером о пользе каждой, и пробуйте! Экспериментируйте и корректируйте процессы под себя, меняйте то, что кажется неподходящим. В итоге через несколько циклов вы обязательно придете к удовлетворительному результату.

Миф: Scrum работает только на стикерах и презентациях

Опровержение: Scrum успешно используется в сложных проектах, включая IT, медицину и прочие отрасли. Это фреймворк, который адаптируется под реальный контекст, а не инструмент для создания иллюзии работы. Повторюсь, что scrum — это не что-то инновационное, модное и подходящее только под кого-то особенного, отнюдь нет! Конечно, первым делом нужно оценить насколько фреймворк применим в вашем контексте и помочь в этом может матрица Стейси.

А далее учитывать, что scrum — это модернизированный и адаптированный фреймворк, в базе которого лежит цикл PDCA, а он в свою очередь основан на эмпиризме: создаем гипотезу, пробуем, смотрим результаты, делаем выводы и строим новые гипотезы на основании полученных результатов и выводах.

Заключение

Критика Scrum зачастую связана с неправильным его использованием или отсутствием понимания ключевых принципов. Скрам-мастер — это не “тварь дрожащая”, а человек, имеющий право и компетенцию помогать командам быть эффективнее и счастливее. Реальный потенциал Scrum раскрывается там, где есть желание учиться и развиваться.

Одна из ценностей Scrum — открытость. Будьте открыты изменениям для того, чтобы становиться лучше для себя и для ваших клиентов. 

А если вы чувствуете сопротивление, то экологичных варианта два: разрешить себе ошибаться и пробовать или перестать страдать самому и перестать мучать окружающих и выбрать работу за пределами Agile и Scrum. 

Больше о моем опыте и взгляде на роль Scrum-мастера в подкасте Дневник Айтишника, где я делюсь практическими советами и мыслями на эту тему. Там вас ждет еще больше полезной информации, которая поможет разобраться в тонкостях профессии.

И подпишитесь на мой Telegram-канал, где я делюсь еще большим количеством инсайтов и размышлений о работе скрам-мастера!

Мне будет интересно узнать, что вы думаете об этой роли. C какими мифами о Scrum-мастерах сталкивались вы?  Какие практики работают, а какие нет? Поделитесь своим опытом в комментариях — давайте обсудим это вместе!