- PVSM.RU - https://www.pvsm.ru -
Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 [1] и часть 2 [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. [3]"
Как лечим: Нужен опытный фасилитатор, который вскрыл бы причины конфликта, чтобы начать улучшать ситуацию. Активная команда и сама может начать собирать факты о деструктивном влиянии разногласий между SM и PO на результаты команды — просто записывая рабочие ситуации. А затем на ретроспективе, где присутствуют оба участника, выдать эти факты, обсудить их и попытаться найти варианты решения. Если же не удается выстроить диалог и всё сводится к поиску виноватых, а не решения, то нужно искать внешнего фасилитатора и эскалировать проблемы за пределы команды.
При этом команде важно не вставать ни на чью сторону: «не втягивайте нас в споры, как договоритесь, так дайте нам знать о решении». Такая позиция будет индикатором существующей проблемы для SM и PO.
Симптом: Scrum master не «проповедует»: не объясняет сути элементов scrum, не проводит обучения, игры, тренинги, позволяющие команде лучше понять scrum и приобщиться к agile культуре. Не объясняет и не даёт команде ответов на вопросы, связанные с процессом. Не знает текущего уровня принятия и понимания scrum членами команды.
Чем плохо: Если нет регулярных встреч команды, где обсуждается scrum, то понимание и вера во фреймворк уходят. Любая культура (agile не исключение) требует подкрепления (не путать с карго [4]-культом), скорее всего не будет работать схема: прошли тренинг, знаем 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 [5] больше одного и работа делается в отсутствии SM, может позволить себе совмещение или работу со второй командой (но не забывая о первой, возможно, воспитывая там замену себе).
Симптом: SM не фасилитирует встречи и совещания. Может либо тянуть одеяло на себя, «знает» ответы на все вопросы, не дает высказываться членам команды. Либо не «ведет» собрания, просто собирает людей, а дальше пускает все на самотек.
Чем плохо: Если SM не фасилитирует, не помогает выстраивать эффективные коммуникации (между членами команды; общение с PO, стейкхолдерами и др.; проведение встреч; и т.д.), то на коммуникации может тратиться много энергии, которую можно было бы направить на разработку продукта. Встречи могут не достигать возложенной на них задачи. Могут возникать конфликты из-за непонимания. И из эффективного инструмента принятия решений, собрания скорее всего превратитятся в источник стресса. А доминирование SM на общих собраниях будет демотивировать команду и негативно сказываться на инициативе и самоорганизации.
Как лечим: SM должен уметь фасилитировать [6]. Его задача — выстроить открытые коммуникации внутри команды; настроить взаимодействие команды с внешним миром; научить команду проводить полезные собрания. SM должен сам осознавать необходимость того или иного собрания, сформулировать цель и повестку встречи, заранее обозначить продолжительность. Во время встречи нужно следить как за повесткой, так и за выделенными временными рамками, прерывать обсуждения на отвлеченные темы, например: «к этой теме мы обязательно вернемся позже, она записана, а сейчас давайте продолжим обсуждение нашего текущего вопроса». Можно попросить кого-то из участников помогать в проведении собраний (или делегировать проведение части собраний команде). В конце каждого собрания важно подводить итог и фиксировать результат. Полезно внедрить инструменты оценки встреч, чтобы в конце участники потратили еще несколько секунд и дали обратную связь (строим эмпирический процесс, там где он может быть полезен). Все результаты стоит донести до всех заинтересованных лиц по завершении встречи, например, письмом.
Симптом: SM не формирует из группы людей настоящую scrum команду. Не выстраивает доверительные профессиональные отношения, не сглаживает углы.
Чем плохо: нежелание общаться, конфликты, нерабочая атмосфера — негативно сказываются на результатах команды. Сплоченные команды дают лучший результат при прочих равных.
Как лечим: одна из важных задач SM сделать так, чтобы группа людей стала командой, т.е. вырастить команду и сделать её зрелой (когда SM стоит в стороне и умиляется). Для этого нужно как можно больше времени проводить с командой, примечать конфликты, чтобы их можно было разрешить и не дать им развиться, понять, как строятся коммуникации (если сидя рядом люди не разговаривают, а пишут друг другу email — это тревожно). SM должен на реальных ситуациях демонстрировать преимущества живого общения над перепиской. Он должен добираться до корневых причин конфликтов и разногласий и помогать людям договариваться друг с другом. Полезный инструмент для анализа — это построение графа коммуникаций (ставим вершинами каждого члена команды, а ребра — это каждый факт общения), анализируя его, можно поискать слабые стороны в коммуникациях (например, общение через одного члена команды — он "узкое горлышко [7]"; либо отсутствие общения между конкретными парами людей). На его основе можно создавать ситуации для «выравнивания» коммуникаций, в которых вы объединяете «не общающихся» людей; и наоборот исключаете из некоторых ситуаций человека, на котором общение замыкается. Полезно и интересно следить за динамикой развития такого графа.
Симптом: SM не развивает команду, не предлагает постоянные изменения, не выводит команду из зоны комфорта, не поддерживает инициативы, а довольствуется текущими успехами: «Мы классные! Мы команда!»
Чем плохо: Если SM не является двигателем изменений (и развития), то скорее всего его команда будет деградировать. Подталкивать к изменениям могут любые участники процесса, но на это не стоит расчитывать. Без изменений в попытке улучшиться, команда со временем будет отставать от требований. Agile — это про способность быстро адаптироваться к изменениям.
Как лечим: SM должен быть инициатором изменений, предлагать пробовать новое в процессах, задачах, внедрять инженерные практики. Нельзя пребывать в состоянии покоя, нужно искать возможности для улучшений. Чтобы понимать, какие изменения делаются и в каком состоянии находятся, можно повысить прозрачность и визуализировать процесс. Работа с командой и её развитие – это работа такая же, как и создание продукта. SM может завести свою доску, на которую он будет помещать эксперименты, action items [8] с ретроспектив, инициативы и т.д. Отсутствие изменений на доске может быть индикатором застоя деятельности 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 в компании и задач, стоящих перед командой. В целом, это очень большой спектр вариантов, но рассмотрим упрощенные случаи:
Еще раз кратко напомню (см. заключение первой части [1]) что делать с полученной информацией:
За три статьи мне удалось описать самые очевидные симптомы ролей в scrum. При этом описание ролей в scrum guide [14] занимает 3 из 19 страниц. Scrum guide говорит «что» нужно делать, но оставляет на усмотрение команд «как делать», потому что это сильно зависит от конкретной ситуации. Мне кажется, важно делиться своими опытом и практиками того, «как» именно вы делаете. Хочется верить, что материал оказался полезным и вы взяли на вооружение «медицинские» карточки, описанные в этой серии статей.
За иллюстрации огромное спасибо Sai Kin [15]!
Автор: Dmitry Podkorytov
Источник [16]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/285414
Ссылки в тексте:
[1] часть 1: https://habr.com/company/wrike/blog/414923/
[2] часть 2: https://habr.com/company/wrike/blog/415563/
[3] The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.: https://www.scrumguides.org/scrum-guide.html#team-sm
[4] карго: https://en.wikipedia.org/wiki/Cargo_cult#Metaphorical_uses_of_the_term
[5] bus factor: https://medium.com/tech-tajawal/the-bus-factor-6ea1a3ede6bd
[6] фасилитировать: https://www.youtube.com/watch?v=97GbxO8fhUg
[7] узкое горлышко: https://en.wikipedia.org/wiki/Bottleneck_(engineering)
[8] action items: https://en.wikipedia.org/wiki/Action_item
[9] Пилотная команда: https://www.scrum.org/resources/blog/ensure-scrum-teams-launch-successfully
[10] организационными дисфункциями: https://ru.wikipedia.org/wiki/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D1%82%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
[11] LeSS: https://less.works/
[12] SAFe: https://www.scaledagileframework.com/
[13] Nexus: https://www.scrum.org/resources/online-nexus-guide
[14] scrum guide: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
[15] Sai Kin: https://vk.com/sai_kinpub
[16] Источник: https://habr.com/post/416189/?utm_source=habrahabr&utm_medium=rss&utm_campaign=416189
Нажмите здесь для печати.