scrum scrum master правильный scrum правильный скрам признаки правильного scrum роль scrum master роль скрам мастера скрам скрам мастер управление продуктом управление проектом scrum

Правильный Scrum: Эпизод 3 - Scrum Master

Mykola Sarry

• 11 min read

Продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору. Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:

  • те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
  • те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
  • фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
  • те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.

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

[sendpulse-form id=”278″]

Взаимодействие с владельцем продукта

Признак правильного Scrum #18 – Скрам-мастер внимательно следит за бэклогом

Симптом: SM не работает с продуктовым backlog. Полностью оставляет его на совести PO. Ждет, что команда будет получать backlog и его элементы в необходимом им виде без участия SM.
Чем плохо: Одна из задач SM — это построение эффективного и прозрачного процесса, в котором всем участникам комфортно работать. SM необходимо следить за всеми элементами scrum, чтобы иметь возможность его улучшать, а backlog продукта — это очень важный артефакт scrum, который нельзя оставлять без внимания SM.
Как лечим: SM следует договориться с PO, чтобы вместе поработать над backlog и понять работу PO; проанализировать процесс; предложить улучшения; предложить свою помощь. SM следует узнать у команды, какие ожидания у них от backlog, как можно его улучшить. Коллективно принять решения по улучшению backlog, его элементов, процесса и активностей по взаимодействию с ним, можно посвятить этому отдельную ретроспективу. И возвращаться к этому вопрос с определенной периодичностью (помним, что в основе scrum лежит эмпирический процесс).

Признак правильного Scrum #19 – Между SM и PO полное взаимопонимание, они вместе идут к общей цели

Симптом: SM не прислушивается к идеям / желаниям PO. Он противопоставляет себя ему. Идет местечковая война за влияние. Нет конструктивного взаимодействия между SM и PO.
Чем плохо: Мне нравится сравнение scrum команды с семьей, эта метафора очень часто помогает понять и объяснить, почему нужно делать так, а не иначе (Просто переносите ситуацию в семью, задавайте вопрос: «Как бы поступили в семье?». Часто вы сможете найти путь к ответу). Сложно назвать счастливым семейство, где постоянно ссорятся мать с отцом, ведь от этого очень сильно страдают дети (ВАЖНО: SM и PO не «родители» команде). Когда нет взаимопонимания и конструктивного взаимодействия между SM и PO, то страдать будет команда: подковерные игры, саботаж открытости и прозрачности. Если SM не может договориться с PO, то он не может решать одну из важнейших своих задач: “The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”
Как лечим: Нужен опытный фасилитатор, который вскрыл бы причины конфликта, чтобы начать улучшать ситуацию. Активная команда и сама может начать собирать факты о деструктивном влиянии разногласий между SM и PO на результаты команды — просто записывая рабочие ситуации. А затем на ретроспективе, где присутствуют оба участника, выдать эти факты, обсудить их и попытаться найти варианты решения. Если же не удается выстроить диалог и всё сводится к поиску виноватых, а не решения, то нужно искать внешнего фасилитатора и эскалировать проблемы за пределы команды.
При этом команде важно не вставать ни на чью сторону: «не втягивайте нас в споры, как договоритесь, так дайте нам знать о решении». Такая позиция будет индикатором существующей проблемы для SM и PO.

Взаимодействие с командой

Признак правильного Scrum #20 – Скрам-мастер является пропеведником и мессией Scrum.

Симптом: Scrum master не «проповедует»: не объясняет сути элементов scrum, не проводит обучения, игры, тренинги, позволяющие команде лучше понять scrum и приобщиться к agile культуре. Не объясняет и не даёт команде ответов на вопросы, связанные с процессом. Не знает текущего уровня принятия и понимания scrum членами команды.
Чем плохо: Если нет регулярных встреч команды, где обсуждается scrum, то понимание и вера во фреймворк уходят. Любая культура (agile не исключение) требует подкрепления (не путать с карго-культом), скорее всего не будет работать схема: прошли тренинг, знаем scrum, scrum взлетел. С течением времени люди накапливают опыт, у них появляются новые вопросы, которые требуют внимания, объяснения. Если не помогать людям разбираться, то они перестанут жить с этими идеями, а утонут в проблемах и непонимании, в конечном счете, разочаруются.
Как лечим: SM, в первую очередь, должен все время обучаться сам, общаться с коллегами, читать статьи, посещать митапы, конференции и т.д. Этими знаниями он должен регулярно делиться с командой / PO / своей организацией: проводить тренинги и игры, иллюстрирующие принципы agile / scrum. Команда / компания развиваются, и надо давать актуальные знания, соответствующие текущим потребностям и запросам. Чтобы осознать эти потребности, нужно больше общаться с людьми на тему процессов и сложностей в работе. SM должен регулярно проводить личные беседы с каждым членом команды, чтобы понимать какие есть ожидания, проблемы, уровень понимания scrum в команде. Как и во многом, что касается scrum, важно задать ритм активностей по развитию agile культуры и scrum внутри команды / компании.

Признак правильного Scrum #21 – SM полностью отдается развитию scrum в команде/компании

Симптом: Частичный SM, например, по совместительству с другой ролью. Причем scrum-мастерит он, когда есть на это время, по-остаточному принципу.
Чем плохо: Если SM полностью не отдается задаче развития scrum в команде / компании, а совмещает это с другой деятельностью, то скорее всего будут страдать все результаты. Быть хорошим SM непросто, а если делать это урывками, то scrum скорее всего будет деградировать. Например: если человек совмещает роли разработчика и SM, в случае проблем с достижением цели спринта, он скорее бросится делать задачи сам, чтобы достичь цели. А это плохо! Самое правильное поведение SM в этой ситуации — настроить команду на достижение результата, развить команду, помочь ей стать лучше.
Как лечим: Если мы говорим про работу SM в еще незрелой команде, то нужно попытаться изыскать способы освободить SM от любой другой работы, кроме scrum-мастерства. Это можно предложить как эксперимент на несколько спринтов, чтобы понять, что это дает команде. Если организация находится на пути апробации agile и scrum, на это должны дать зеленый свет. После проведения эксперимента стоит всеми заинтересованными лицами оценить результаты и принять решения о судьбе scrum, выделенных SM и agile культуры вообще.
SM, вырастивший зрелую команду, в которой bus factor больше одного и работа делается в отсутствии SM, может позволить себе совмещение или работу со второй командой (но не забывая о первой, возможно, воспитывая там замену себе).

Признак правильного Scrum #22 – SM выступает фасилитатором на встречах и совещаниях

Симптом: SM не фасилитирует встречи и совещания. Может либо тянуть одеяло на себя, «знает» ответы на все вопросы, не дает высказываться членам команды. Либо не «ведет» собрания, просто собирает людей, а дальше пускает все на самотек.
Чем плохо: Если SM не фасилитирует, не помогает выстраивать эффективные коммуникации (между членами команды; общение с PO, стейкхолдерами и др.; проведение встреч; и т.д.), то на коммуникации может тратиться много энергии, которую можно было бы направить на разработку продукта. Встречи могут не достигать возложенной на них задачи. Могут возникать конфликты из-за непонимания. И из эффективного инструмента принятия решений, собрания скорее всего превратитятся в источник стресса. А доминирование SM на общих собраниях будет демотивировать команду и негативно сказываться на инициативе и самоорганизации.
Как лечим: SM должен уметь фасилитировать. Его задача — выстроить открытые коммуникации внутри команды; настроить взаимодействие команды с внешним миром; научить команду проводить полезные собрания. SM должен сам осознавать необходимость того или иного собрания, сформулировать цель и повестку встречи, заранее обозначить продолжительность. Во время встречи нужно следить как за повесткой, так и за выделенными временными рамками, прерывать обсуждения на отвлеченные темы, например: «к этой теме мы обязательно вернемся позже, она записана, а сейчас давайте продолжим обсуждение нашего текущего вопроса». Можно попросить кого-то из участников помогать в проведении собраний (или делегировать проведение части собраний команде). В конце каждого собрания важно подводить итог и фиксировать результат. Полезно внедрить инструменты оценки встреч, чтобы в конце участники потратили еще несколько секунд и дали обратную связь (строим эмпирический процесс, там где он может быть полезен). Все результаты стоит донести до всех заинтересованных лиц по завершении встречи, например, письмом.

Признак правильного Scrum #23 – SM способен сделать из набора людей настоящую scrum-команду

Симптом: SM не формирует из группы людей настоящую scrum команду. Не выстраивает доверительные профессиональные отношения, не сглаживает углы.
Чем плохо: нежелание общаться, конфликты, нерабочая атмосфера — негативно сказываются на результатах команды. Сплоченные команды дают лучший результат при прочих равных.
Как лечим: одна из важных задач SM сделать так, чтобы группа людей стала командой, т.е. вырастить команду и сделать её зрелой (когда SM стоит в стороне и умиляется). Для этого нужно как можно больше времени проводить с командой, примечать конфликты, чтобы их можно было разрешить и не дать им развиться, понять, как строятся коммуникации (если сидя рядом люди не разговаривают, а пишут друг другу email — это тревожно). SM должен на реальных ситуациях демонстрировать преимущества живого общения над перепиской. Он должен добираться до корневых причин конфликтов и разногласий и помогать людям договариваться друг с другом. Полезный инструмент для анализа — это построение графа коммуникаций (ставим вершинами каждого члена команды, а ребра — это каждый факт общения), анализируя его, можно поискать слабые стороны в коммуникациях (например, общение через одного члена команды — он “узкое горлышко“; либо отсутствие общения между конкретными парами людей). На его основе можно создавать ситуации для «выравнивания» коммуникаций, в которых вы объединяете «не общающихся» людей; и наоборот исключаете из некоторых ситуаций человека, на котором общение замыкается. Полезно и интересно следить за динамикой развития такого графа.

Признак правильного Scrum #24 – SM постоянно развивает команду, расширяет ее зону комфорта

Симптом: SM не развивает команду, не предлагает постоянные изменения, не выводит команду из зоны комфорта, не поддерживает инициативы, а довольствуется текущими успехами: «Мы классные! Мы команда!»
Чем плохо: Если SM не является двигателем изменений (и развития), то скорее всего его команда будет деградировать. Подталкивать к изменениям могут любые участники процесса, но на это не стоит расчитывать. Без изменений в попытке улучшиться, команда со временем будет отставать от требований. Agile — это про способность быстро адаптироваться к изменениям.
Как лечим: SM должен быть инициатором изменений, предлагать пробовать новое в процессах, задачах, внедрять инженерные практики. Нельзя пребывать в состоянии покоя, нужно искать возможности для улучшений. Чтобы понимать, какие изменения делаются и в каком состоянии находятся, можно повысить прозрачность и визуализировать процесс. Работа с командой и её развитие – это работа такая же, как и создание продукта. SM может завести свою доску, на которую он будет помещать эксперименты, action items с ретроспектив, инициативы и т.д. Отсутствие изменений на доске может быть индикатором застоя деятельности SM. Долго работая с командой, у SM может замыливаться взгляд, есть угроза перестать видеть возможности для улучшения, тогда можно либо оставить команду одну на какое-то время (с одной стороны это полезно SM, с другой стороны это хорошая проверка зрелости команды, как они себя поведут в отсутствии SM), либо попросить помощи со стороны, например, договориться с SM соседней команды поменяться на некоторое время, чтобы помочь друг другу найти точки роста.

Признак правильного Scrum #25 – SM отстаивает чистоту и принципы Scrum

Симптом: SM позволяет работать не по scrum, спокойно относится к саботажу. Например:
“- да вроде же спринт прошел без факапов, давайте ретру не будем проводить, что обсуждать то?
— ок, проведем в следующий раз.”
Чем плохо: Если SM не отстаивает чистоту и необходимость scrum перед командой, PO, компанией, то вряд ли это будет делать кто-то еще. Если принципы не защищаются, то нет ощущения их важности и полезности. SM положено быть очень адаптивным и лояльным к любым изменениям. Хороший SM не говорит «нет», он говорит «давайте попробуем. Проведем эксперимент.». Но относительно принципов фреймворка scrum нужно быть стойким и четко понимать, какие есть артефакты, события, ритуалы, ценности и прочие элементы scrum, и для чего они необходимы, какие задачи решают. Фреймворк меняют уже зрелые команды, на этапе становления scrum нельзя давать слабину и отходить от scrum guide (нарушив одно из правил, встаёт резонный вопрос: а почему бы не нарушить и другое?).
Как лечим: одна из задач SM — следить за «чистотой» scrum, и, пока команда не достигнет зрелости, он должен подавлять все бунты и саботажи, направленные на scrum. SM полезно проводить упражнения по взаимодействию со скептиками. Хорошо найти подкованного «скептика», например, коллегу SM и проводить с ним упражнения: попросить его саботировать scrum, а SM должен парировать. Нужно быть готовым отвечать на вопросы, зачем мы проводим scrum события, что плохого, если мы пропустим одно из событий, зачем мне (члену команды) делать что-то. Если SM сам не знает ответов, то стоит обратиться к сообществу, посетить тренинг, почитать литературу.

Признак правильного Scrum #26 – SM выстраивает самоорганизующуюся команду

Симптом: SM выдает распоряжения членам команды, ведет себя как директивный руководитель. Такое может случаться, если роль SM отдали бывшему линейному руководителю, при этом не объяснив, что должно измениться в работе, подходах, коммуникациях.
Чем плохо: Когда SM ощущает власть и начинает вести себя как директивный руководитель (распределение задач, вещание на собраниях и т.д.), это убивает командность, демотивирует людей, и это уже не scrum. Можно ставить крест на самоорганизации.
Как лечим: хороший вариант — это отправить такого SM на тренинг, где ему расскажут об agile культуре, дадут новые инструменты работы с командой. Другой более сложный вариант — самой команде пытаться менять коммуникации с SM: строить диалог, брать на себя ответственность при принятии локальных решений, предлагать альтернативы решениям SM. Еще можно подумать о переходе роли к другому члену команды.

Взаимодействие с компанией

Признак правильного Scrum #27 – Scrum Master целиком и полностью живет культурой Agile и Scrum

Симптом: Scrum master не разделяет ценностей agile. Это культура ему не близка, сам он придерживается других взглядов. Так бывает если SM назначили человека, а не сам он проявлял желание выполнять эту роль.
Чем плохо: Если человек не верит в культуру agile, не разделяет ценности, но при этом он SM, то скорее всего он преследуют весьма корыстные цели, и вряд ли сможет принести в этих условиях пользу команде, продукту, компании.
Как лечим: Ищем / воспитываем / обучаем SM, понимающего и разделяющего ценности agile, и осознавшего scrum: что и для чего делается. Ставим ему задачу запустить scrum, даем команду, PO, продукт. Важно осознать, какие задачи стоят перед scrum в организации. Нужно сразу определить, как мы поймем, что scrum работает, как мы будем это оценивать, с помощью каких метрик.

Признак правильного Scrum #28 – Scrum Master транслирует успехи своей команды на уровень компании стремясь внедрить scrum всюду

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

  • Пилотная команда в компании, думающей о применений scrum: Это настоящий вызов для SM. Его команда под пристальным взглядом всей компании. Как можно поступить:
    1. Выяснить (возможно разработать совместно с инициаторами изменений) какая задача стоит перед scrum в компании? Для чего запускается «пилот»? Какая гипотеза проверяется? Как будет оцениваться результат? Договорится о длительности эксперимента и о точке принятия решения о судьбе scrum в компании.
    2. Донести эту информация до команды. Разработать визуализацию индикаторов, за которыми собирается следить компания. Регулярно актуализировать визуальные индикаторы.
    3. Максимально открыто вести работу. Давать возможность работникам компании наблюдать за новыми для компании процессами, только не в ущерб команде. Регулярно информировать о ходе работы всю компанию.
    4. К назначенному сроку подготовить данные о результатах, полученных во время проведения эксперимента (работы пилотной команды). Провести обширную ретроспективу по решению судьбы scrum в компании.
  • Одна из команд в компании, где часть сотрудников работают по scrum, а часть нет: Скорее всего компания находится в процессе перехода. И SM должен помогать переходу всей компании на scrum. Что можно делать в таком случае:
    • Поддерживать прозрачность относительно процессов и результатов команды, распространять эту информацию внутри компании (открытые sprint review, информационные рассылки и т.п.).
    • Организовать лигу SM, где «опылять» друг друга свежими идеями, практиками. Делиться опытом и оказывать друг другу поддержку.
    • Совместно с другими SM бороться с организационными дисфункциями.
    • Принимать участие в работе «не scrum» сотрудников, обучать их scrum, предлагать изменения в их процессах (если изменение может привести к улучшению).
  • Команда в компании полностью работающей по Scrum и применяющей различные способы масштабирования scrum: LeSS, SAFe, Nexus и т.д.: Тут на плечи SM ложится вопрос синхронизации команд. У меня нет реального опыта работы в подобных компаниях, поэтому воздержусь от предложений. Но было бы очень интересно почитать про ваш опыт — пишите в комментариях.

Заключение

Еще раз кратко напомню что делать с полученной информацией:

  1. выбираем самый актуальный для себя симптом;
  2. обсуждаем с командой его негативное влияние, как отправная точка к рассуждениям берите мои тезисы;
  3. командой придумываете способы снять симптом;
  4. делаете то, что придумали;
  5. анализируете полученные результаты;
  6. повторите с первого пункта.

За три статьи мне удалось описать самые очевидные признаки правильности scrum и симптомы неправильности. Scrum guide говорит «что» нужно делать, но оставляет на усмотрение команд «как делать», потому что это сильно зависит от конкретной ситуации. Хочется верить, что материал оказался полезным и вы взяли на вооружение признаки правильности и симптомы неправильности, описанные в этой серии статей.