HR - SCRUM-мастер. Это как?

История о том, как HR стал скрам-мастером у разработчиков.

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

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

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

Через пару месяцев ко мне пришел CTO с просьбой помониторить рынок SCRUM-мастеров, потому что наш скрам-мастер раньше был в режиме консультанта, а сейчас нагрузка на него выросла в два раза и ему нужна помощь. Я поискала варианты и поняла, что во-первых их мало, а во-вторых, все они стоят дорого, а в компании не будет полной загрузки на такого человека.

И тогда я подумала - а почему бы мне не попробовать себя в роли скрам-мастера?

Дейли у нас ведут тимлиды, планирование тоже, скрам-мастеру остается ретроспектива и улучшение командного взаимодействия (разруливание сложностей в команде, подключение ко всем вопросам, обратная связь и взаимодействие с командой). То есть по функционалу - все, что и так делает HR + ретроспектива.

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

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

Сейчас, по прошествии нескольких месяцев работы в таком режиме, количество наших команд увеличилось, и мы наняли еще одного скрам-мастера нам в помощь. У нас образовалась небольшая Agile-команда, где мы обсуждаем возникающие сложности. Это кстати очень удобно для HR в маленьких командах - ведь вокруг тебя одни технари и обычно не с кем проконсультироваться или поделиться болями. А теперь у меня такая возможность есть!

Еще один неявный плюс вижу такой. Мы с нашим тимлидом в марте были на конференции Pycon и общались с ребятами из других компаний. Обсуждаем наши процессы, и тут один из разработчиков говорит: “О, у вас тоже есть скрам-мастеры? А у вас их в команде любят?” Мы немного растерялись и говорим - “Эээ, ну у нас вроде всех любят, да”. А у них в команде скрам-мастеров не любят. Оказалось, что у них скрам-мастер это выделенная роль на фуллтайм, и команда не понимает, чем они занимаются. Всем кажется, что пока команда вкалывает, скрам-мастер отдыхает. А совмещать роль скрам-мастера с какой-то из ролей в разработке не совсем правильно, это конфликт интересов.

В нашем случае у команды нет такого негатива, потому что для всех скрам-мастеров эта роль парт-тайм, а у HR конфликта интересов с командой не возникает.

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

В общем, HRы, дерзайте! Роль скрам-мастера или Agile-коуча отлично ложится на функционал HR и помогает сделать нашу работу более осознанной :).