Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:
- те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
- те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
- фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
- те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.
Со Scrum и SM-ами, мне кажется, происходит очень похожая история. Попробуйте посмотреть на знакомых вам SM через такую призму. С какими SM вам бы хотелось работать?
Давайте разберемся, какие тревожные симптомы могут быть у SM.
Взаимодействие с владельцем продукта
Симптом: SM не работает с продуктовым backlog. Полностью оставляет его на совести PO. Ждет, что команда будет получать backlog и его элементы в необходимом им виде без участия SM.
Чем плохо: Одна из задач SM — это построение эффективного и прозрачного процесса, в котором всем участникам комфортно работать. SM необходимо следить за всеми элементами scrum, чтобы иметь возможность его улучшать, а backlog продукта — это очень важный артефакт scrum, который нельзя оставлять без внимания SM.
Как лечим: SM следует договориться с PO, чтобы вместе поработать над backlog и понять работу PO; проанализировать процесс; предложить улучшения; предложить свою помощь. SM следует узнать у команды, какие ожидания у них от backlog, как можно его улучшить. Коллективно принять решения по улучшению backlog, его элементов, процесса и активностей по взаимодействию с ним, можно посвятить этому отдельную ретроспективу. И возвращаться к этому вопрос с определенной периодичностью (помним, что в основе scrum лежит эмпирический процесс).
Симптом: 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 master не «проповедует»: не объясняет сути элементов scrum, не проводит обучения, игры, тренинги, позволяющие команде лучше понять scrum и приобщиться к agile культуре. Не объясняет и не даёт команде ответов на вопросы, связанные с процессом. Не знает текущего уровня принятия и понимания scrum членами команды.
Чем плохо: Если нет регулярных встреч команды, где обсуждается scrum, то понимание и вера во фреймворк уходят. Любая культура (agile не исключение) требует подкрепления (не путать с карго-культом), скорее всего не будет работать схема: прошли тренинг, знаем scrum, scrum взлетел. С течением времени люди накапливают опыт, у них появляются новые вопросы, которые требуют внимания, объяснения. Если не помогать людям разбираться, то они перестанут жить с этими идеями, а утонут в проблемах и непонимании, в конечном счете, разочаруются.
Как лечим: SM, в первую очередь, должен все время обучаться сам, общаться с коллегами, читать статьи, посещать митапы, конференции и т.д. Этими знаниями он должен регулярно делиться с командой / PO / своей организацией: проводить тренинги и игры, иллюстрирующие принципы agile / scrum. Команда / компания развиваются, и надо давать актуальные знания, соответствующие текущим потребностям и запросам. Чтобы осознать эти потребности, нужно больше общаться с людьми на тему процессов и сложностей в работе. SM должен регулярно проводить личные беседы с каждым членом команды, чтобы понимать какие есть ожидания, проблемы, уровень понимания scrum в команде. Как и во многом, что касается scrum, важно задать ритм активностей по развитию agile культуры и scrum внутри команды / компании.
Симптом: Частичный SM, например, по совместительству с другой ролью. Причем scrum-мастерит он, когда есть на это время, по-остаточному принципу.
Чем плохо: Если SM полностью не отдается задаче развития scrum в команде / компании, а совмещает это с другой деятельностью, то скорее всего будут страдать все результаты. Быть хорошим SM непросто, а если делать это урывками, то scrum скорее всего будет деградировать. Например: если человек совмещает роли разработчика и SM, в случае проблем с достижением цели спринта, он скорее бросится делать задачи сам, чтобы достичь цели. А это плохо! Самое правильное поведение SM в этой ситуации — настроить команду на достижение результата, развить команду, помочь ей стать лучше.
Как лечим: Если мы говорим про работу SM в еще незрелой команде, то нужно попытаться изыскать способы освободить SM от любой другой работы, кроме scrum-мастерства. Это можно предложить как эксперимент на несколько спринтов, чтобы понять, что это дает команде. Если организация находится на пути апробации agile и scrum, на это должны дать зеленый свет. После проведения эксперимента стоит всеми заинтересованными лицами оценить результаты и принять решения о судьбе scrum, выделенных SM и agile культуры вообще.
SM, вырастивший зрелую команду, в которой bus factor больше одного и работа делается в отсутствии SM, может позволить себе совмещение или работу со второй командой (но не забывая о первой, возможно, воспитывая там замену себе).
Симптом: SM не фасилитирует встречи и совещания. Может либо тянуть одеяло на себя, «знает» ответы на все вопросы, не дает высказываться членам команды. Либо не «ведет» собрания, просто собирает людей, а дальше пускает все на самотек.
Чем плохо: Если SM не фасилитирует, не помогает выстраивать эффективные коммуникации (между членами команды; общение с PO, стейкхолдерами и др.; проведение встреч; и т.д.), то на коммуникации может тратиться много энергии, которую можно было бы направить на разработку продукта. Встречи могут не достигать возложенной на них задачи. Могут возникать конфликты из-за непонимания. И из эффективного инструмента принятия решений, собрания скорее всего превратитятся в источник стресса. А доминирование SM на общих собраниях будет демотивировать команду и негативно сказываться на инициативе и самоорганизации.
Как лечим: SM должен уметь фасилитировать. Его задача — выстроить открытые коммуникации внутри команды; настроить взаимодействие команды с внешним миром; научить команду проводить полезные собрания. SM должен сам осознавать необходимость того или иного собрания, сформулировать цель и повестку встречи, заранее обозначить продолжительность. Во время встречи нужно следить как за повесткой, так и за выделенными временными рамками, прерывать обсуждения на отвлеченные темы, например: «к этой теме мы обязательно вернемся позже, она записана, а сейчас давайте продолжим обсуждение нашего текущего вопроса». Можно попросить кого-то из участников помогать в проведении собраний (или делегировать проведение части собраний команде). В конце каждого собрания важно подводить итог и фиксировать результат. Полезно внедрить инструменты оценки встреч, чтобы в конце участники потратили еще несколько секунд и дали обратную связь (строим эмпирический процесс, там где он может быть полезен). Все результаты стоит донести до всех заинтересованных лиц по завершении встречи, например, письмом.
Симптом: SM не формирует из группы людей настоящую scrum команду. Не выстраивает доверительные профессиональные отношения, не сглаживает углы.
Чем плохо: нежелание общаться, конфликты, нерабочая атмосфера — негативно сказываются на результатах команды. Сплоченные команды дают лучший результат при прочих равных.
Как лечим: одна из важных задач SM сделать так, чтобы группа людей стала командой, т.е. вырастить команду и сделать её зрелой (когда SM стоит в стороне и умиляется). Для этого нужно как можно больше времени проводить с командой, примечать конфликты, чтобы их можно было разрешить и не дать им развиться, понять, как строятся коммуникации (если сидя рядом люди не разговаривают, а пишут друг другу email — это тревожно). SM должен на реальных ситуациях демонстрировать преимущества живого общения над перепиской. Он должен добираться до корневых причин конфликтов и разногласий и помогать людям договариваться друг с другом. Полезный инструмент для анализа — это построение графа коммуникаций (ставим вершинами каждого члена команды, а ребра — это каждый факт общения), анализируя его, можно поискать слабые стороны в коммуникациях (например, общение через одного члена команды — он "узкое горлышко"; либо отсутствие общения между конкретными парами людей). На его основе можно создавать ситуации для «выравнивания» коммуникаций, в которых вы объединяете «не общающихся» людей; и наоборот исключаете из некоторых ситуаций человека, на котором общение замыкается. Полезно и интересно следить за динамикой развития такого графа.
Симптом: SM не развивает команду, не предлагает постоянные изменения, не выводит команду из зоны комфорта, не поддерживает инициативы, а довольствуется текущими успехами: «Мы классные! Мы команда!»
Чем плохо: Если SM не является двигателем изменений (и развития), то скорее всего его команда будет деградировать. Подталкивать к изменениям могут любые участники процесса, но на это не стоит расчитывать. Без изменений в попытке улучшиться, команда со временем будет отставать от требований. Agile — это про способность быстро адаптироваться к изменениям.
Как лечим: SM должен быть инициатором изменений, предлагать пробовать новое в процессах, задачах, внедрять инженерные практики. Нельзя пребывать в состоянии покоя, нужно искать возможности для улучшений. Чтобы понимать, какие изменения делаются и в каком состоянии находятся, можно повысить прозрачность и визуализировать процесс. Работа с командой и её развитие – это работа такая же, как и создание продукта. SM может завести свою доску, на которую он будет помещать эксперименты, action items с ретроспектив, инициативы и т.д. Отсутствие изменений на доске может быть индикатором застоя деятельности SM. Долго работая с командой, у SM может замыливаться взгляд, есть угроза перестать видеть возможности для улучшения, тогда можно либо оставить команду одну на какое-то время (с одной стороны это полезно SM, с другой стороны это хорошая проверка зрелости команды, как они себя поведут в отсутствии SM), либо попросить помощи со стороны, например, договориться с SM соседней команды поменяться на некоторое время, чтобы помочь друг другу найти точки роста.
Симптом: SM позволяет работать не по scrum, спокойно относится к саботажу. Например:
"- да вроде же спринт прошел без факапов, давайте ретру не будем проводить, что обсуждать то?
— ок, проведем в следующий раз."
Чем плохо: Если SM не отстаивает чистоту и необходимость scrum перед командой, PO, компанией, то вряд ли это будет делать кто-то еще. Если принципы не защищаются, то нет ощущения их важности и полезности. SM положено быть очень адаптивным и лояльным к любым изменениям. Хороший SM не говорит «нет», он говорит «давайте попробуем. Проведем эксперимент.». Но относительно принципов фреймворка scrum нужно быть стойким и четко понимать, какие есть артефакты, события, ритуалы, ценности и прочие элементы scrum, и для чего они необходимы, какие задачи решают. Фреймворк меняют уже зрелые команды, на этапе становления scrum нельзя давать слабину и отходить от scrum guide (нарушив одно из правил, встаёт резонный вопрос: а почему бы не нарушить и другое?).
Как лечим: одна из задач SM — следить за «чистотой» scrum, и, пока команда не достигнет зрелости, он должен подавлять все бунты и саботажи, направленные на scrum. SM полезно проводить упражнения по взаимодействию со скептиками. Хорошо найти подкованного «скептика», например, коллегу SM и проводить с ним упражнения: попросить его саботировать scrum, а SM должен парировать. Нужно быть готовым отвечать на вопросы, зачем мы проводим scrum события, что плохого, если мы пропустим одно из событий, зачем мне (члену команды) делать что-то. Если SM сам не знает ответов, то стоит обратиться к сообществу, посетить тренинг, почитать литературу.
Симптом: SM выдает распоряжения членам команды, ведет себя как директивный руководитель. Такое может случаться, если роль SM отдали бывшему линейному руководителю, при этом не объяснив, что должно измениться в работе, подходах, коммуникациях.
Чем плохо: Когда SM ощущает власть и начинает вести себя как директивный руководитель (распределение задач, вещание на собраниях и т.д.), это убивает командность, демотивирует людей, и это уже не scrum. Можно ставить крест на самоорганизации.
Как лечим: хороший вариант — это отправить такого SM на тренинг, где ему расскажут об agile культуре, дадут новые инструменты работы с командой. Другой более сложный вариант — самой команде пытаться менять коммуникации с SM: строить диалог, брать на себя ответственность при принятии локальных решений, предлагать альтернативы решениям SM. Еще можно подумать о переходе роли к другому члену команды.
Взаимодействие с компанией
Симптом: Scrum master не разделяет ценностей agile. Это культура ему не близка, сам он придерживается других взглядов. Так бывает если SM назначили человека, а не сам он проявлял желание выполнять эту роль.
Чем плохо: Если человек не верит в культуру agile, не разделяет ценности, но при этом он SM, то скорее всего он преследуют весьма корыстные цели, и вряд ли сможет принести в этих условиях пользу команде, продукту, компании.
Как лечим: Ищем / воспитываем / обучаем SM, понимающего и разделяющего ценности agile, и осознавшего scrum: что и для чего делается. Ставим ему задачу запустить scrum, даем команду, PO, продукт. Важно осознать, какие задачи стоят перед scrum в организации. Нужно сразу определить, как мы поймем, что scrum работает, как мы будем это оценивать, с помощью каких метрик.
Симптом: SM не занимается организацией обмена опытом между командами. Не транслирует успехи команды на уровень компании. Не обеспечивает прозрачность результатов и процессов его команды для всей организации.
Чем плохо: команда существует внутри компании, она обладает высокой степенью автономности, но тем не менее тесно связана с компанией. Если команда замкнута на себе, то она может оторваться от реалий компании, может стать ненужной или неактуальной, могут возникать неоправданные ожидания в обоих направлениях и т.д.
Как лечим: Все зависит от уровня agile в компании и задач, стоящих перед командой. В целом, это очень большой спектр вариантов, но рассмотрим упрощенные случаи:
- Пилотная команда в компании, думающей о применений scrum: Это настоящий вызов для SM. Его команда под пристальным взглядом всей компании. Как можно поступить:
- Выяснить (возможно разработать совместно с инициаторами изменений) какая задача стоит перед scrum в компании? Для чего запускается «пилот»? Какая гипотеза проверяется? Как будет оцениваться результат? Договорится о длительности эксперимента и о точке принятия решения о судьбе scrum в компании.
- Донести эту информация до команды. Разработать визуализацию индикаторов, за которыми собирается следить компания. Регулярно актуализировать визуальные индикаторы.
- Максимально открыто вести работу. Давать возможность работникам компании наблюдать за новыми для компании процессами, только не в ущерб команде. Регулярно информировать о ходе работы всю компанию.
- К назначенному сроку подготовить данные о результатах, полученных во время проведения эксперимента (работы пилотной команды). Провести обширную ретроспективу по решению судьбы scrum в компании.
- Одна из команд в компании, где часть сотрудников работают по scrum, а часть нет: Скорее всего компания находится в процессе перехода. И SM должен помогать переходу всей компании на scrum. Что можно делать в таком случае:
- Поддерживать прозрачность относительно процессов и результатов команды, распространять эту информацию внутри компании (открытые sprint review, информационные рассылки и т.п.).
- Организовать лигу SM, где «опылять» друг друга свежими идеями, практиками. Делиться опытом и оказывать друг другу поддержку.
- Совместно с другими SM бороться с организационными дисфункциями.
- Принимать участие в работе «не scrum» сотрудников, обучать их scrum, предлагать изменения в их процессах (если изменение может привести к улучшению).
- Команда в компании полностью работающей по Scrum и применяющей различные способы масштабирования scrum: LeSS, SAFe, Nexus и т.д.: Тут на плечи SM ложится вопрос синхронизации команд. У меня нет реального опыта работы в подобных компаниях, поэтому воздержусь от предложений. Но было бы очень интересно почитать про ваш опыт — пишите в комментариях.
Заключение
Еще раз кратко напомню (см. заключение первой части) что делать с полученной информацией:
- выбираем самый актуальный для себя симптом;
- обсуждаем с командой его негативное влияние, как отправная точка к рассуждениям берите мои тезисы;
- командой придумываете способы снять симптом;
- делаете то, что придумали;
- анализируете полученные результаты;
- повторите с первого пункта.
За три статьи мне удалось описать самые очевидные симптомы ролей в scrum. При этом описание ролей в scrum guide занимает 3 из 19 страниц. Scrum guide говорит «что» нужно делать, но оставляет на усмотрение команд «как делать», потому что это сильно зависит от конкретной ситуации. Мне кажется, важно делиться своими опытом и практиками того, «как» именно вы делаете. Хочется верить, что материал оказался полезным и вы взяли на вооружение «медицинские» карточки, описанные в этой серии статей.
За иллюстрации огромное спасибо Sai Kin!
