Скрам-мастер должен разбираться в инженерных практиках! А должен ли?

Статья рассуждение...

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

От кого же я слышу запрос, что скрам-мастер должен разбираться в инженерных практиках? Слышу я его из двух направлений. Первое – это лидеры трансформации, руководители agile-офисов, которые сами выходцы из разработки, второе – это люди, которые никогда не были ни скрам-мастерами ни Agile-коучами и в целом, от них можно услышать «Я вообще не понимаю, чем они в команде занимаются».

Теперь давайте порассуждаем с вами на предмет необходимости знаний скрам-мастеру инженерных практик.

В моей голове сразу возникает несколько вопросов «Зачем?», «Что с этими знаниями хотите делать?», «Насколько глубокими должны быть эти знания?». Если у вас есть чёткие ответы на эти вопросы – буду рада их прочитать в комментариях.

С кем работает скрам-мастер? Он работает с кросс-функциональной ИТ-командой, которая состоит из бизнес-аналитиков, системных-аналитиков, фронт- и бэк-разработчиков, тестировщиков (которые делятся на функциональных и авто-тестировщиков). Внимание вопрос: какую предметную область должен знать скрам-мастер (TDD, BDD, CI/CD и т.д.)? Все? А реально ли это, да и зачем ему?

Допустим, вы решили, что вам нужен скрам-мастер, который хорошо понимает область бэк-разработчика. Сразу же возникают вопросы:

- насколько глубоко и по какому языку программирования (PHP, C++, JS …)?

- какие обязанности вы хотите, чтобы выполнял скрам-мастер в данной части? Если не разрабатывать, навык теряется, разрабатывать, команды не видишь...

И так можно пройтись по каждому стеку, а дальше и по тестировщикам и по системному анализу…

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

Если вы ещё уверены в том, что скрам-мастер, должен обладать знаниями в области инженерных практик, тогда двинемся дальше по обязанностям, целям и задачам скрам-мастера

Если вы откроете Руководство по Скрам, то можете легко найти ответ, чем занимается скрам-мастер в команде, однако, в руководстве много белых пятен, которые я постараюсь коротенько раскрыть здесь.

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

Скрам-мастер должен довести команду до состояния самостоятельности в течение года, после этого он «уходит» из команды, у него появляется в подопечных уже не одна, а команды три, с которыми он работает.

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

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

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

Скрам-мастер понимает, что необходимо выстраивать поток, чтобы процесс шёл бесперебойно/беспрепятственно с момента взятия обязательств перед заказчиками, а это дискавери+деливери. И здесь появляется необходимость знания Канбан-метода, не просто доску настроить, а внедрить метрики, чтобы на их основании можно было всей скрам-командой принимать решения.

Работает с людьми – самое важное и самое сложное – это выдерживать баланс между важностью достижения результата и созданием/сохранением команды. Скрам-мастер – это тот человек, который проводит 1:1 с участниками команды, чтобы понять как у них дела в части психологического состояния, мотивации. Да, он своего рода внутренний HR или специалист по счастью. Команда бурлит, у неё могут быть конфликты, как внутри себя, так и с внешним миром. Задача Cкрам-мастера – научить команду эффективно разрешать конфликты, уметь разговаривать друг с другом и договариваться как внутри команды, так и с другой частью организации. Он работает клеем, который помогает команде достичь уровня не просто эффективных процессов, но и результативных.

Скрам-мастер задаёт много каверзных вопросов. Если же он будет хорошо разбираться в предметной области кого-то из деливери, то может "поймать" туннельный взгляд, будет без вопросов соглашаться и тем самым пропадёт эффект, когда Скрам-мастер своими вопросами бросает вызов (челленджит). А может произойти такое, что хорошо разбираясь в чём-то передавит команду, будет сильно доминировать и вступит в конфликт с лидерами компетенции. Например, упорно будет говорить в своей команде, что надо переходить на BDD или TDD, в то время как этого не требовалось при приёме на работу от разработчиков и лидер-компетенции пока тоже не видит смысла в переходе.

Как же это будет происходить, если Скрам-мастер далёк от инженерных практик, а у команды с ними всё плохо.

Кейс: Девелоперы не успевают сделать инкремент за спринт (2 недели).

SM: команда, как сделать так, чтобы мы успевали за 2 недели?

Команда – генерит идеи.

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

SM: берёт ответ «лучше декомпозировать» и начинается серия вопросов, он же командный коучинг: а что у нас сейчас не так? Что вы вкладываете в «лучше декомпозировать»?

Если команда под декомпозицией понимает «разорвать» элемент бэклога по технологическому стеку, Скрам-мастер напоминает, что инкремент – это сущность, которая приносит ценность клиенту. Дальше вопрос: если мы сделаем только бэк, что ценного получит клиент?

Кто-то из команды: круто будет уже использовать BDD?

Другой из команды: у меня нет практики, я не знаю что это?

SM: Как BDD улучшит работу?

Участник команды рассказывает. Если все соглашаются, что это круто и готовы в это пойти, Скрам-мастер спрашивает, кто готов взять задачку по обучению, чья помощь потребуется и т.д.

Через такой командный коучинг Скрам-мастер учит команду думать, общаться, самостоятельно находить лучшие решения.

Так зачем же ему знать инженерные практики? Выдавать готовые ответы, а точно ли это ответы?

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

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

А теперь задайтесь вопросом, требуете ли вы от разработчиков, тестировщиков, аналитиков при приёме на работу умение фасилитировать встречи, настраивать фреймворк Скрам, выстраивать дискавери-процесс?

Дочитывая эту статью, я хочу, чтобы вы ушли с пониманием, того, что со временем каждый участник команды обогащается новыми словами из словаря своего со-командника. Владелец продукта начинает разбираться в ограничениях системы, при этом разбирается не сильно глубоко, чтобы не было туннельного мышления – когда заказчику говорится «нет», хотя давно пора заняться развитием системы, потому что заказчики могут уйти к конкурентам из-за нашего «нет». Владелец продукта понимает важность устранения технического долга, потому что иначе станет очень дорого выводить функциональность. Девелоперы понимают, что такое бизнес-ценность и перестают мыслить только своим стеком, а также понимают, что если тестирование не прошли, то опоздали все – мы в одной лодке. Скрам-мастер тоже начинает больше разбираться во всяких словечках команды, чтобы на их же языке задавать им вопросы и если в одной команде используется понятие ПРОД, то в другой команде могут использовать ПРОМ и к этому тоже Скрам-мастер привыкает. Это не знание инженерных практик – это владение словарём. Как Девелоперы и Владелец продукта начинают владеть словарём Скрам-мастера, так и Скрам-мастер – словарём Владельца продукта и Девелоперов.

Всё ещё настаиваете на том, что Скрам-мастер должен владеть инженерными практиками?

Если эти знания будут плюсом ко всему тому, что первично должен знать скрам-мастер, такой Скрам-мастер – самый дорогой сотрудник в вашей команде и он не ещё тот десятирукий Шива: замечает всё, что происходит в команде со всеми сразу и с каждым по отдельности.

За свои 6 лет Agile-практики подобного я ещё не встречала. Найдёте – дайте знать, познакомлюсь 😏

Анастасия Бутова-Никишина – основатель компании "Лаборатория ПроЛидеров", основатель и тренер Школы Скрам-мастеров, Эксперт в области диагностики и развития эмоционального интеллекта, Эксперт стратегий разрешения конфликтов, Agile-консультант