Начало работы с новой командой — это всегда волнительно. Даже если это не первая команда Скрам Мастера, как правило, это абсолютно новый опыт. В основном каждый из нас в этой ситуации действует интуитивно, но мы решили собрать совокупный опыт нашего небольшого комьюнити, оформить его в гайда и поделиться с вами. Начнем, пожалуй, с актуализации проблемы.
Проблема сложности перенимания экспертизы
Очень часто новый участник команды разработки имеет возможность перенять экспертизу у своих новых коллег, которые на ежедневной основе занимаются тем же, чем и он. У Скрам Мастера такой роскоши, как правило, нет. Он приходит в команду и оказывается там единственным носителем своей экспертизы. Зачастую бывает даже так, что команда ранее не работала со Скрам Мастером. Тогда задача синхронизироваться и начать продуктивную совместную работу сильно усложняется. На начальных этапах взаимодействия можно допустить ошибки и упустить важные детали из виду. На обмен знаниями в таких условиях рассчитывать не приходится.
Проблема неполноты картины
Эта проблема вытекает из предыдущей. Со своей перспективы Скрам Мастер не видит всю картину ситуации в команде, на это нужно не только время, но и правильные вопросы и коммуникации.
Необходимость наладить контакт
Команды не всегда положительно настроены к новому Скрам Мастеру — у них бывает много сомнений, плюс они не всегда являются волонтерами. Это даже не основная проблема. Во взаимодействии может быть много острых углов: уровень самоорганизованности команды, корпоративная и внутрикомандная культура, внутренние конфликты и т. д. Скрам Мастер должен быть как лидером, так и другом. А это значит, что, выходя в новую команду, Скрам Мастеру необходимо в короткие сроки завоевать доверие и авторитет.
Скрам Мастер может столкнуться с сопротивлением и даже с саботажем
На команду накладывается отрицательный предыдущий опыт, что приводит к сопротивлению, а в некоторых случаях и явному саботажу. Скрам Мастер может столкнуться с шутками в его адрес, непониманием роли и вопросами из разряда «А чем ты можешь нам помочь? Зачем ты нужен?» В таких случаях пригодится крепкая нервная система, хорошее чувство юмора и умение давать людям обратную связь.
Распространенные ошибки Скрам Мастера
- Натягивание фреймворка
Очень печальная история получается с начинающими Скрам Мастерами, когда они, имея представление лишь об одном фреймворке, пытаются протолкнуть его везде без понимания контекста. А потом в интернете появляются статьи с названиями «Скрам терроризм» или «Скрам не работает».
2. Попытка взять на себя всю ответственность
Если ваша команда недостаточно вовлечена во время встречи или пришла на неё неподготовленной, проясните, в чем причина. Не стоит воспринимать это на свой счет. Попытка Скрам Мастера взять на себя всю ответственность за команду будет мешать самоорганизации и приведет его к эмоциональному выгоранию. В конце концов нельзя помочь людям, если они этого не хотят.
3. Игнорирование собственного выгорания
Выгоревший Скрам Мастер в лучшем случае бесполезен для команды, а в худшем — будет плохо на неё влиять. Как говорится, сначала наденьте кислородную маску на себя, а потом — на ребенка. В начале мы должны научиться сами находить баланс между работой и отдыхом, научиться пребывать в ресурсном состоянии и черпать вдохновение от своей работы.
4. Менять процесс без ведома заинтересованных лиц
Я сама наблюдала такой кейс, когда Скрам Мастер, поработав месяц в команде, решил перевести ее на Канбан. Он продал эту идею команде, но не посоветовался с Владельцем Продукта. В итоге Владелец Продукта был оповещен об изменениях только постфактум Естественно, уровень доверия в команде сильно упал. Нужно понимать, что все члены команды имеют общие интересы. И вместо попыток протолкнуть собственную инициативу выгоднее построить команду, в которой голос каждого имеет вес.
5. «Так написано в Скрам Гайде»
Довольно типичная ошибка начинающего Скрам Мастера — это пытаться сделать все по книжке. Никогда не отвечайте команде на вопрос «Зачем мы это делаем?» фразой «Так написано в Скрам Гайде». Такой ответ лишь выдает неглубокое знание фреймворка и слепой фанатизм.
Поведенческие стратегии
В первую очередь нужно понять, что самая выгодная роль — это быть самим собой. Некоторая фальшь в поведении Скрам Мастера довольно быстро прочувствуется и распространится на остальных. Мы посвящаем довольно большую часть жизни работе. Готовы ли мы все это время притворяться кем-то кем мы не являемся? Нужно быть достаточно смелым, чтобы разрешить себе просто быть самим собой. Когда люди вокруг видят, что их принимают со всеми недостатками и особенностями, они понимают, что они на своем месте. Это приносит гармонию и взаимопонимание в коллектив, формирует доверие и уважение. И, как показывает практика, именно такая атмосфера помогает раскрыть в людях таланты.
Выстраиваем безопасную среду
Наверняка вы сталкивались с такими руководителями, которые говорят что-то вроде «мне не интересны ваши проблемы, мне нужны ваши решения». Такого руководителя вряд ли можно назвать лидером-слугой. Если выстраивать цепочку, то можно проследить следующее: руководитель транслирует эту идею на команду, а участники команды усваивают простую схему: говорить о проблемах — плохо, озвучивать только успех — хорошо. В такой среде любой человек будет чувствовать дискомфорт и тревогу, что где-то кто-то узнает о какой-то его неудаче. Таким образом тебе сложно поделиться с коллегами какими-то своими наблюдениями и экспертизой. Ты максимально закрываешься в себе и получается, что команда превращается в группу разрозненных специалистов, главная проблема которых — как бы никто не узнал о моей ошибке. Уменьшится ли от этого количество ошибок? Едва ли. Пострадает ли прозрачность в команде? Безусловно. И со временем становится ясно, что такой подход скорее вредит, чем помогает.
Что делает Скрам Мастер? На своём опыте он может показать, что ошибаться — это нормально, что любой специалист может чего-то не знать. В таком случае, если возникнет какая-то проблема, она станет известна команде довольно быстро. Следовательно, приступить к её решению можно будет своевременно.
Выявить уровень самоорганизации команды
Для каждого уровня самоорганизации нужен определённый подход. Чтобы примерно представлять этот уровень, можно воспользоваться методом Майка Кона из статьи «ситуативное лидерство». По сути дела, достаточно определить возможность и желание команды быть самостоятельными и выбирать свою стратегию поведения. Например, если команда не хочет и не может быть самоорагнизованной, то можно действовать как человек, дающий конкретные советы.
Просить о помощи
Сделать всё самостоятельно — это не цель скрам мастера. Внутри команды усилия Скрам Мастера должны быть направлены на то, чтобы привести команду к самоорганизации. И здесь хорошо работает собственный пример. Логика такая: вы смело просите о помощи; команда понимает, что это никак не уменьшает вашу компетенцию; и это разрушает барьер, если таковой имеется.
Выстраивать личные границы
Часто бывает так, что команда подшучивает над своим Скрам Мастером. И шутки могут быть разные — от вполне безобидных до тех, которые действительно могут задеть. А иногда шутки могут стать индикатором непонимания процессов. В таких случаях нужно уметь выстроить границы. Честно сказать, если вас шутки задевают. Или же проследите, что именно вызывает те или иные шутки. Например, команда часто говорит что-то вроде: «Наконец-то ретроспектива! Можно не работать!» Это может указывать на то, что пора менять формат ретро или искать способы сделать эту встречу более эффективной. Однако порой на некоторые шутки стоит отвечать ответными шутками или преувеличением. Иногда шутки являются неотъемлемой частью культуры команды.
Связь со внешним миром
Десантируясь в новую команду, не забывайте о том, что комьюнити Скрам Мастеров всегда может помочь вам увидеть ситуацию с разных сторон. Здорово, если такое комьюнити есть в вашей организации, но также всегда можно следить за митапами, интервизиями и конференциями, которые проводят в других компаниях. Чем разнообразнее опыт, в который можно погрузиться, тем быстрее можно научиться новому или понять свои ошибки.
Минимальные действия
Есть всего 4 вещи, сделав которые, Скрам Мастер может избежать большинства проблем и опасностей в будущем.
- Выравняться в ожиданиях
Как правило у команды и Владельца Продукта есть конкретные проблемы, с которыми они рассчитывают обратиться к Скрам Мастеру. Проведите небольшую встречу, где вы выравняетесь в ожиданиях от вашей работы. После такой встречи и сбора проблем можно составить процессный Road Map и рассказать о нем команде. Так ваши действия и ваша работа будут максимально прозрачны для всех.
2. Объяснить свою роль и зону ответственности
Роль Скрам Мастера достаточно сложна для понимания. Поэтому хорошим тоном будет рассказать, как вы видите свою роль в команде. На конкретных примерах объясните, на какую помощь от вас команда может рассчитывать, что входит в вашу зону ответственность, а что нет.
3. Договориться об обратной связи
Попросите давать вам обратную связь в случае, если ваши действия будут расходиться с ожиданиями. Покажите свою готовность выслушать конструктивную критику вашей работы и готовность меняться в случае необходимости. Такое поведение также может стать хорошим примером для остальных и будет способствовать становлению культуры обратной связи.
4. Разберитесь в контексте
Если Скрам Мастер не понимает предметной области, в которой команда существует, то он выглядит человеком из мира единорогов. Контекст команды может быть очень разносторонней и сложной штукой, в которой нужно разбираться очень тщательно. Давайте рассмотрим этот вопрос подробнее.
Вхожение в контекст
Для Скрам Мастера очень важно понимать контекст, в котором находится его команда. Довольно часто мы обращаем внимание на внутреннюю кухню команды, но забываем о внешних факторах и рисках, влияющих на работу. Поэтому для лучшего понимания контекста мы выбрали классическое для менеджмента деление на внешнюю и внутреннюю среду.
Приведенные ниже блоки — это области, на которые Скрам Мастеру стоит обратить внимание. Получив ответы на вопросы в этих блоках, Скрам Мастер может дать оценку ситуации в команде и составить для себя списк проблем, над которыми стоит работать.
Внутренняя среда
| Команда | |
| Роли | Какие роли есть в Команде Разработки? |
| Вовлеченность | Все ли в команде выделены на 100%? |
| Опыт | Как довно люди работают в команде/организации? |
| Co-location | Все ли находятся в одной локации? |
| Иерархия | Формальная и неформальная иерархия в команде |
| Вакансии | Есть ли открытые вакнсии? Планируется ли еще набор? |
| Психологические аспекты | Кто лидеры в команде? Доминанты? Инноваторы? Консерваторы? Скептики? Кто эмоционально выгорает? |
| OnBoarding | Как происходит обучение и адаптация новых сотрудников? |
| Информирование | Как сообщаются важные новости команде? |
| Регламенты команды | |
| Командное соглашение | Есть/нет |
| Definition of Ready | Есть/нет |
| Definition of Done | Есть/нет |
| Обучение в команде | |
| Обратная связь | Есть/нет |
| Оценка задач | Есть/нет |
| Декомпозиция задач | Есть/нет |
| Процесс (фреймворк/метод) | Есть/нет |
| Продукт/Бизнес область | |
| Product Owner | Какими полномочиями обладает? |
| Видение | Есть/нет |
| Road Map | Есть/нет |
| Границы продукта | Есть/нет |
| Стратегия | Есть/нет |
| Product Backlog | Как выглядит Product Backlog? Насколько он актуален ? Насколько он открыт для стейкхолдеров и команды? |
| Цели | Какие цели/ KPI стоят перед командой? |
| Продуктовые метрики | Есть/нет |
| Бюджет | Как бюджетируется команда? |
| Технологии | |
| Инженерные практики | Какие инженерные практики команда применяет или пробовала применять? |
| Релизная политика | Как часто команда может выводить готовый функцианал в прод? |
| Зависимости от других команд | Есть ли зависимости на техническом уровне от других команд? |
| Инцидент менеджмент | Как происходит работа с инцидентами? Чья это зона ответственности? |
| Технический долг | Есть ли у команды выделенное время для работы над тех. долгом? Как приоритизируются технические задачи? |
| Звездная карта/ T-shape карта | Есть/нет |
| Архитектура | С какими системами есть интеграции? Что будет если системы с которыми мы интегрируемся перестанут корректно работать? |
| Информационная безопасность | Кто отвечает за ИБ? Как происходит коммуникация и в какой момент? |
| Стандарты | Есть ли у организации технологические стандарты. Кто отвечает за их внедрение? |
| Процесс | |
| Визуализация процесса | Есть/нет |
| Процессные метрики | Есть/нет |
| Мероприятия | Как проходят мероприятия в команде? Имеют ли они ценность для команды? |
Внешняя среда
| Ближняя внешняя среда | |
| Роли влияющие на команду | SWA? Центры экспертизы? Представители на уровне правления? CTO? HR? Вендоры? |
| Карта стейкхолдеров | Есть/нет |
| Карта зависимостей | Есть/нет |
Следующие блоки нельзя назвать обязательными. В команде Владелец Продукта должен обладать знаниями в этих областях. Однако если Скрам Мастер будет напоминать Владельцу Продукта мониторить актуальную картину по этим вопросам, это может быть крайне полезно для команды.
| Дальняя внешняя среда | |
| Клиент/пользователь | Кто клиент/пользователь? Как собирается обратная связь? |
| Рынок | Какая ситуация на рынке? |
| Конкуренты | Кто основные конкуренты? Какие у них преимущества/недостатки? |
| Государство | Какие законопроекты могут повлиять на работу команды? |
Авторы статьи: Ломакова Анастасия, Кочарян Эмилиа
Приняли участие в сборе информации: Федулова Светлана, Щербаков Никита, Соколов Кирилл, Кручинина Мария