scrum в маркетинге
Кейсы

Нужен ли вашему маркетингу Scrum? Как мы внедрили этот фреймворк в Unisender

Анастасия Кремень
стала scrum-мастером

Год назад мы в Unisender внедрили Scrum в команду маркетинга. Так я стала Scrum-мастером — человеком, который отвечает за эффективность команды и соблюдение правил Scrum.

Рассказываю, как внедрить скрам в ваш маркетинг на примере Unisender.

Scrum — это подход в работе (фреймворк), который основан на принципе «инспектируй и адаптируйся». Так работа команды и ее результаты синхронизируются с постоянно меняющимися условиями внешнего мира.

Scrum существует в противовес фреймворкам, в которых все планы, задачи и документация пишутся на старте проекта, и работа делается по линейному плану (пример — фреймворк Waterfall). И только в конце этого жесткого процесса мы получим готовый продукт. 

В Scrum весь процесс работы разбивается на циклы (например, 2 недели работы), которые называются спринтами. В конце каждого спринта команда реализует часть рабочего продукта. Также Scrum создан для того, чтобы быстро адаптироваться под изменения внешнего мира и внедрять это в продукт.

Почему без Scrum могут получаться нежизнеспособные продукты

Команда разработчиков в 2018 году делает продукт, в котором нужно платить физической пластиковой картой. Под это они пишут требования, описывают детали, создают архитектуру проекта и дизайн. Через три года они выпускают продукт. А мир так изменился за это время, что все перешли на бесконтактные платежи и продукт мало кому интересен. 

В Scrum вектор разработки изменился бы в процессе. Скорее всего, разработчики адаптировали бы продукт под новые условия внешнего мира.

Дальше я вкратце расскажу о теории скрама — будет полезно, если вы никогда не сталкивались с этим фреймворком. А если хотите сразу узнать, как мы внедряли скрам в Unisender, то переходите в этот раздел.

Курс о проджект-менеджменте в Школе UniSender
Расскажем, как коммуницировать с командой, вести проекты и работать с разными методологиями. Длительность — 8 недель, все в онлайне.
Учиться
Нужен ли вашему маркетингу Scrum? Как мы внедрили этот фреймворк в Unisender 1

Scrum: теория

В Scrum много англоязычной терминологии. Ее эквиваленты на русском редко используются, поэтому я буду давать два варианта терминов: на русском и на английском.

Роли в Scrum-команде. Классическая Scrum-команда для разработки состоит из:

  • владельца продукта (Product Owner);
  • Scrum-мастера (Scrum-master);
  • команды разработки (3-9 фулл-тайм разработчиков). 

Команда разработки должна быть собрана в таком составе, который позволит достигать поставленных перед командой и продуктом целей. В Scrum-команде нет иерархии, но есть ответственность каждого члена команды. Основные характеристики Scrum-команды: самоорганизованность и кросс-функциональность.

виды участников команды

Владелец продукта (или Product Owner) ответственный за достижение целей продукта. Например, он отвечает за содержание продукта, его стратегическое развитие, проводит необходимые исследования пользователей и рынка. Все это владелец продукта отображает в продуктовом бэклоге (Product Backlog) — тактическом плане работ, списке задач для команды.

Scrum-мастер (или Scrum-master) ответственный за выполнение Scrum в команде, а также за эффективность команды. Он тренирует и учит участников команды эффективной работе, фасилитирует (направляет) команду, устраняет препятствия в работе, помогает команде быть сфокусированной на выполнении целей. Scrum-мастер — это такой менеджер-психолог-коуч для команды, который разными методами помогает команде достигать целей.

Команда разработки (или Developers Team) — программисты и другие специалисты, в таком составе, который поможет достичь поставленной продуктовой цели. Эту цель задает владелец продукта. Внутри этой команды нет иерархии, каждый участник — полноценный специалист, способный реализовать свою часть задач.

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

Спринт (или Sprint) — время, за которое команда реализует часть рабочего продукта. Спринт может длиться одну, две или даже три недели. У каждого спринта есть своя цель, например: добавить платежную систему в продукт, выпустить новый раздел на сайте, разработать процесс регистрации в сервисе. В конце спринта должен быть понятный итог, его называют инкрементом, который является частью продукта. После окончания одного спринта, начинается новый спринт.

В середине спринта происходит проработка бэклога (или Backlog Grooming/Product Backlog Refinement), за которую ответственный владелец продукта. На этой встрече необходимо собрать информацию, чтобы описать задачи на будущий спринт. На планировании спринта (или Sprint Planning) Scrum-команда выбирает те задачи из бэклога, которые они готовы выполнить за будущий спринт исходя из поставленной владельцем продукта цели спринта. Таким образом формируется спринт-бэклог (Sprint Backlog). 

В течение спринта ежедневно проходят 15-минутные утренние встречи — стендапы (или Daily Stand-up), чтобы команда могла синхронизироваться. В конце спринта проходит ревью работ (или Sprint Review), на котором обсуждаются результаты работы и статус достижения цели спринта. Ретроспектива спринта (или Sprint Retrospective) — это встреча, на которой обсуждаются процессы работы, успехи, а также сложности, которые нужно исключить на будущее.

По такому циклу проходят все спринты
По такому циклу проходят все спринты

Артефакты в Scrum. Артефакты — это атрибуты и инструменты для работы команды: Scrum-доска, продуктовый и спринт-бэклоги.

Scrum-доска (или Scrum board) — «таск-менеджер» для Scrum-команды. На ней отображен спринт-бэклог (список задач на спринт), задачи, которые находятся в процессе выполнения, на стадии ревью (проверки), а также выполненные задачи. Доска может быть физическая со стикерами на стене в офисе, а может быть цифровая в специальных программах (например, Trello или Jira).

Продуктовый бэклог — список всех задач, которые нужно выполнить (или Product Backlog), им управляет владелец продукта. Владелец продукта ответственный за его наполнение и описание задач для команды, чтобы они смогли работать с ними.

Спринт-бэклог (или Sprint Backlog) — это список описанных задач для команды, с которыми она работает в текущем спринте.

Так выглядит классическая Scrum-доска
Так выглядит классическая Scrum-доска

Больше про Scrum можно почитать в скрам-гайде, в книге «Scrum: революционный метод управления проектами» Джеффа Сазерленда, а также в статье в Базе знаний Unisender. Я же хочу рассказать, как эту систему переложить на маркетинговый процесс. 

Зачем маркетингу Scrum

От маркетинга хотят одновременно и креатива, и системности, и ориентации на бизнес-метрики, и способности делать шумные кампании для рынка. Это сложно организовать для команды, где часть — креативщики, которым нелегко быть системными, а другая часть — технические специалисты (таргетологи, РРС и SEO-специалисты). Такой командой тяжело управлять и часто мы можем заметить перекос во всей команде: либо она сфокусирована на бренде и имидже, либо — на перформансе и достижениях KPI.

В отделе маркетинга Unisender как раз такая ситуация: у нас есть и креативщики, и технические специалисты. Например, дизайнер и копирайтер скорее думают о внешнем виде и смысле рекламного материала, чем о способности его конвертироваться в заявки. А таргетолог, РРС-специалист или SEO-специалист часто не готовы идти на компромисс и выбирать креативные подходы в ущерб их конверсионности. Я думаю, что SEO-шник готов писать на сайте «эКспрессо», потому что именно так ищут пользователи в Google :). 

Мы смогли найти тот вариант Scrum, который помогает нам работать эффективно. Вот почему мы вообще решили переходить на этот фреймворк.

Развитие самостоятельности и инициативности. В Scrum придерживаются ценностей: приверженности, сфокусированности, открытости, уважения и смелости. 

  1. Приверженность целям проекта, команде и помощи друг друга помогают тимбилдингу и развитию команды. 
  2. Благодаря сфокусированности на целях продукта, проекта, спринта, а также поставленных KPI, команда не распыляется на ненужную работу и всегда держит свои цели в фокусе. 
  3. Открытость процесса работы помогает развивать честность, самостоятельность, ответственность за свою работу, благодаря чему специалисты развиваются в команде, помогая ей расти. Например, если мы что-то не успеваем — мы говорим об этом открыто. Если у нас есть проблемы и конфликты — мы готовы выносить их на ретроспективу, обсуждать и решать внутри команды. 
  4. В Scrum-команде принято уважать мнение каждого члена команды, рассматривать его и приходить к консенсусу. Таким образом у сотрудников развивается инициативность, так как он чувствует, что его мнение важно для других и для проекта. 
  5. Смелость команды проявляется в том, чтобы начать делать новый продукт, чтобы экспериментировать и делать челленджи. 

Если вы и ваша команда реально готовы быть верны этим ценностям, то со временем вы увидите, что самостоятельность и инициативность — это характеристики членов вашей команды. Идеи и ответственность за них будут возникать постоянно, вам останется только поставить их на рельсы и реализовывать. 

Мы в Unisender убедились в этом. Когда мы внедрили плоскую структуру и понятный процесс реализации проектов, сотрудники стали сами инициировать проекты и даже браться за их реализацию.

Раскрытие креативности и потенциала. Так как обычно от команды маркетинга требуют креативности, нужно работать над созданием условий для раскрытия потенциала сотрудников. В этом может помочь фасилитация, которая является обязанностью Scrum-мастера. Фасилитация — это подход к работе с командой, когда менеджер не дает готовые ответы или решения для группы. Он направляет группу к принятию общего решения, достижению консенсуса и разделению ответственности за эти решения. При этом каждый член команды может высказаться, а затем из множества свежих мнений и идей фасилитатор помогает группе отобрать самые эффективные. При этом запрещена любая критика идей, только конструктивные переговоры и общая оценка всех идей, вне зависимости, кто их автор.

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

Фасилитацию можно противопоставить авторитарному менеджменту.

Авторитарный менеджер Фасилитатор
«Ты действительно думаешь, что это нужно сейчас делать?» — обесценивание идеи. «Скажи, пожалуйста, почему ты считаешь это важным для достижения нашей цели» — вывод на цель и оценка идеи относительно цели проекта.
«Я принял решение, что мы будем промотировать эту акцию по Телеграмм каналам. Маша, побери каналы и отдай мне на утверждение» — принял решение за команду и Маша не будет воспринимать задачу как «свою». «Мы придумали такую-то акцию. Как вы думаете, в каких каналах лучше всего ее промотировать?» — команда выберет каналы и затем участников нужно подтолкнуть к действиям: «Давайте теперь определимся, кто за какой канал будет отвечать и пропишет сейчас план и сроки реализации».

 

Наиболее фундаментальная книга по этой теме — «Руководство фасилитатора: как привести группу к принятию совместного решения» Сэма Кейнера.

Быть в тренде: подход «инспектируй и адаптируй». Этот подход означает что нужно постоянно оценивать ситуацию внутри и снаружи команды и продукта, замечать изменения, тренды, ситуативы и адаптировать свою работу. Для маркетинга — это чуть ли не самое главное, так как нужно постоянно отслеживать инфоповоды и внедрять в кампании. Команда всегда может следить за тенденциями, и брать их в работу на ближайший спринт. В других фреймворках пришлось бы ждать конца месяца или квартала, когда команда будем заново составлять планы.

Как мы внедряли Scrum в маркетинг

Мы внедрили Scrum за 8 шагов. Рассказываю о каждом из них в подробностях.

 

Шаг 0 

Понять, нужен ли Scrum

Внедрение нового фреймворка — всегда стресс для команды. Поэтому стоит хорошо подумать, точно ли вам это нужно. И точно ли вам нужен именно Scrum. Если вы менеджер и думаете о таком фреймворке, ответьте (лучше вместе с командой) на такие вопросы:

  1. У меня большая команда маркетинга и я не успеваю один за всеми следить?
  2. А я точно готов передать ответственность в руки самих сотрудников, и мне не так важно держать самому все на контроле?
  3. Есть ли у меня четкое понимание целей и задач отдела маркетинга?
  4. Мне важна самостоятельность и развитие каждого сотрудника?
  5. Я готов участвовать в работе как полноценный член команды и давать сотрудникам высказываться и принимать решения?
  6. Мне точно не важна жесткая иерархия в отделе?
  7. Я хочу уйти от излишней бюрократизации процесса маркетинга во имя развития креатива и ориентации на результаты?
  8. Мне важно быть в тренде и подхватывать ситуативы во внешней коммуникации?
  9. Готов ли я придерживаться ценностей Scrum и транслировать их на всю команду?

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

Если вы решились на трансформацию лучше определить ее цели и прописать их по SMART. Возможно, через время что-то нужно будет изменить. 

Определите самые больные точки вашей команды и пропишите работу с ними в виде целей. Например, вы хотите развить креативность и инициировать участие в ситуативах. Пропишите это как цель: «Через 6 месяцев после внедрения Scrum минимум половина команды начнет раз в месяц предлагать новые идеи и ситуативы, а также брать ответственность за их выполнение». И через обозначенное время сделайте проверку.

 

Шаг 1 

Переложить структуру Scrum-команды на команду маркетинга

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

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

Как было у нас

У нас в маркетинге более 10 проектов, у каждого из них есть владелец, который отвечает за выполнение проекта: ведет бэклог, проводит планирование и обзор результатов, собирает команду. Scrum-мастер есть не на каждом проекте, где-то эту роль частично выполняет и владелец проекта, но в общем Scrum-мастер (а это я) понемногу включен во все проекты и работу всех членов команды. 

Команды проекта у нас собраны таким образом, чтобы работа по проекту была эффективной. Например, в команде по сайту есть дизайнер, разработчики, SEO специалист, копирайтеры. Этот же дизайнер и копирайтер состоит в команде по SMM, но цели и задачи по этим проектам разные.

Так устроена структура проектов в маркетинге Unisender.

Так устроена структура проектов в маркетинге Unisender. У нас есть 3 основных облака. В каждом облаке — несколько направлений со своими владельцами, скрам-мастерами и командой

Шаг 2 

Определить фреймворк и особенности работы с задачами

Нужно определиться, где у вас в работе проект, а где процесс. У проекта есть четкое начало и завершение, есть понятные конечные цели. Можно сказать, что команда собирается, выполняет проект и расходится. Например, проект — это запуск акции, которая имеет четкие временные рамки. У нее есть этап подготовки, реализации, завершения, анализа. Можно четко прописать этапы работ, переложить их на двухнедельные спринты в виде задач и вся команда будет над ними работать. Для таких проектов идеально подходит Scrum.

В случае процесса нельзя четко обозначить начало и конец. Это обычные операционные процессы маркетинга. Например, постоянные рекламные кампании по платному трафику в поисковой выдаче, ведение страничек в социальных сетях, SEO-оптимизация сайта. Речь идет именно о рутинной работе отдела маркетинга. Для таких процессов хорошо подойдет фреймворк ScrumBan. Это комбинация Scrum и другого подхода — Kanban (Scrum + Kanban = Scrumban). 

В канбане тоже используется доска, но немного с другими колонками. Спринтов в канбане нет. Этот фреймворк хорошо подходит для операционной работы — в нем не нужно обязательно выполнить все задачи за спринт. Больше про канбан можно почитать в статье в Базе знаний Unisender.

 

Различия Scrum и Kanban

Scrum Kanban
Временные циклы планирования задач Есть — спринт Опционально
На какую метрику опираться при планировании Количество задач, которые может сделать команда на спринт, чтобы достичь цели спринта Рабочие часы специалистов
Количество задач на команду Реально выполнить за один спринт Не важно, делаются по мере свободы специалиста
Роли 3 заданные роли (владелец продукта, Scrum-мастер, команда разработки) Нет заданных ролей, каждый специалист — специалист по своей части
Доска Обновляется на каждый спринт Постоянная
Кросс-функциональность команды Обязательно Опционально — могут быть специалисты одной специальности
Так выглядит классическая Kanban-доска
Так выглядит классическая Kanban-доска
А это доска для работы по Scrum
А это доска для работы по Scrum

Чтобы понять, какая комбинация и какой порядок работы подходит вам, поговорите с владельцами проектов. Обсудите, как проходит работа по проекту и как вы сможете формализовать процесс и настроить доску. 

Вы можете сделать физическую доску в офисе на стене (она должна быть всегда на видном месте для всех) или наладить диджитал-вариант. Для этого можно использовать Trello, Basecamp (с расширением Tracked), Jira.

Как было у нас

Для проектов, по типу акций, мы используем Scrum. 

Для операционных процессов мы используем разные вариации ScrumBan. На некоторых проектах у нас есть бэклог проекта и спринты, но нет спринт-бэклога и жесткого условия выполнения всех задач за спринт. Также мы проводим необходимые события (встречи Scrum). Например, на таком фреймворке построена работа блога и базы знаний Unisender.

задачи движутся по Kanban-доске

В блоге задачи движутся по Kanban-доске — есть этап заявки, написания, редактуры и проверки. По такому алгоритму проще вести задачи и нет жесткой привязки к спринтам

Шаг 3

Найти Agile-чемпионов в команде и заручиться их поддержкой

Самое время найти соратников! Вам будет легче внедрить изменения, если часть команды будет за них. Спросите, кому из команды было бы интересно протестировать новый подход на своих проектах. Скорее всего откликнутся самые гибкие и готовые к изменениям люди, их и нужно найти. Таких людей называют Agile-чемпионами. С помощью них вы сможете протестировать свои гипотезы по внедрению фреймворка, обкатать Scrum-встречи и провести тестовый запуск на их проектах. Самое главное — вы получите их моральную поддержку и помощь, с поддержкой Agile-чемпионов вам будет легче внедрять изменения на всю команду.

Как было у нас

Когда мы начинали внедрять Scrum в Unisender я спросила, кому из команды было бы интересно протестировать Scrum на своем проекте. Откликнулись пара человек, с которыми я назначила несколько встреч. На встречах я рассказала про Agile и Scrum, описала преимущества для нас, мы разобрались с их проектами и обсудили формат работы по внедрению Scrum. 

Когда мы обкатали фреймворк на проектах Agile-чемпионов, мы представили результаты на всю команду. Нас было трое, поэтому кредит доверия команды был выше, чем если бы я предлагала изменения одна.

Шаг 4

Наладить проекты

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

Как было у нас

Когда мы внедряли Scrum, то начали с небольших проектов на один месяц. Например, над акцией на Черную пятницу работал весь отдел, мы заранее спланировали бэклог проекта, расставили задачи на спринты, проводили все необходимые встречи. Мы протестировали фреймворк на одном проекте и теперь используем его и для остальных проектов такого типа.

Шаг 5

Наладить процессы

Определите список процессов, роли в них (здесь, кстати, можно обойтись без Scrum-мастера), настройте доску для работы, определите необходимые встречи. Запустите процесс вместе с Agile-чемпионом и дальше масштабируйте на другие процессы. Обычно операционки больше, чем проектов, поэтому уделите этому достаточно внимания.

Как было у нас

У нас есть два типа процессов: операционные — например, блог, где постоянно пишется контент, и проектные. 

В операционном процессе мы используем скрамбан и доску, где задачи просто делаются потоком одна за одной. Тем не менее этот процесс мы укладываем в спринты с двухнедельным планированием объема задач. Это важно, потому что команда большая и в процессе задействованы многие специалисты, у которых есть другие задачи. Поэтому работа при двухнедельном планировании помогает лучше спланировать задачи конкретного специалиста.

В проектных процессах мы используем больше артефактов Scrum: доска со спринт-бэклогом, спринты по 2 недели и встречи. Примеры таких проектов: доработка маркетингового сайта, проекты по перфоманс-маркетингу, контент-проекты. У них нет четкого начала и конца, но есть постоянная команда и бэклог работ, поэтому такой вид организации для нас наиболее приемлемый.

Шаг 6

Провести тренинг для команды

Итак, все получилось. Удалось отладить проекты и процессы, протестировать их вместе с Agile-чемпионом, внести корректировки и вы уверены в том, что это нужно внедрять на всех. Самое время научить команду новому подходу. Для этого стоит провести вводный тренинг и обучение, к которым надо хорошо подготовиться. 

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

После тренинга нужно собраться с каждым владельцем проекта и обсудить детали конкретного проекта или процесса. Понять, как происходит работа сейчас, дать варианты внедрения Scrum или скрамбан и помочь настроить работу.

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

Шаг 7

Запуститься и помогать

Когда все команды определили флоу задач, настроили доски, запланировали необходимые встречи и подготовили бэклог, время запускаться и проводить первое планирование. Определите срок тестового запуска: у нас это было 3 месяца. Будет сложно и непонятно, нужно будет постоянно искать информацию, чтобы решать сложности, помогать, коучить друг друга, договариваться и привыкать. 

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

 

Шаг 8 

Измерить и адаптировать

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

Как было у нас

В Unisender отдел маркетинга работает по Scrum почти год. У нас были сложности, потому что трансформация команды занимает долгое время. Эта трансформация всегда начинается с физического уровня: проведения необходимых встреч и налаживания досок, а заканчивается изменением майндсета команды. Поэтому организационных сложностей пугаться не стоит, их надо пережить и пройти с командой.

Вот несколько сложностей, с которыми столкнулись мы:

Был болезненный переезд в Jira. Мы долгое время работали в Basecamp, который выглядит просто как список задач по проекту. Затем мы установили расширение Tracked на него, который позволил создавать доски. Дальше мы переехали в Jira, и вот тут начались проблемы. Многие члены команды отвергали ее на физическом уровне, не хотели работать в ней. Оказалось, что просто не все ее понимали, так как Jira достаточно сложная.

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

Люди не хотели менять подход к задачам. После перехода на Jira многие продолжали воспринимать ее как список задач на день, как было в случае с Basecamp. Очень сложно вот так сразу переключиться на подход к задачам — как не к задачам специалиста, а к задачам проекта, которые надо решить, чтобы достичь цели. Это тоже заняло время и это нормальный процесс. Нужно объяснять и дать понимание команде, дать примеры и показать разницу твоих задач на день и задач проекта. Еще помогло то, что к спринт-планированию мы подключили всю команду (ранее ходили только тимлиды). Это помогло научиться всем планировать проекты, а не список задач за неделю.

Люди не хотели ходить на встречи. Например, некоторые члены команды отвергали обзор спринта или планирование спринта, считая, что они бесполезны. Это было связано с тем, что ранее планирование и обзоры проводили только тимлиды и остальные члены команды не понимали, зачем им эти встречи. Я сильно попросила дать этому шанс и месяц походить на эти встречи и выполнять все требования. С тем, кто особо упирался, проводила личную встречу и объясняла, зачем эти коллы, какая у них задача и просила попробовать месяц.

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

Работали по Scrum? С каким проблемами столкнулись?

В комментарии

Комментарии