Как избежать возможных ошибок при переходе на Scrum?

Сейчас во многих компаниях перестраивают бизнес-процессы для работы по методологии Scrum. Но при этом действительно работают по Scrum единицы. Как настроить правильный Scrum и не скатиться в карго-культ? Разбираемся вместе с Артуром Неком — управляющим партнером Kaiten, аккредитованным Kanban-тренером и консультантом по Agile, Scrum и классическому проектному управлению. 

Для каких проектов лучше всего подойдёт Scrum

Обрисуем сначала ситуацию, когда Scrum не очень подойдет: 

• Если ваш бизнес работает уже давно, много процессов уже запущено.
• Либо у вас много зависимостей между подразделениями внутри компании, и одна маленькая группа не может реализовать весь цикл запуска – от идеи до вывода продукта на рынок. 
• Если, к примеру, разработку нужно согласовывать на совете директоров, который проходит раз в полгода. Тогда все бенефиты Scrum нивелируются: ведь главные бонусы от применения этого метода – быстрое получение знаний о том, что нужно клиенту и каких продуктов не хватает на рынке.

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

Внедряем Scrum в работу своей компании: с чего начать?

Первое и главное на начальном этапе: в команде должна появиться роль владельца продукта (product owner). Владелец продукта составляет бэклог продукта (перечень рабочих задач, расположенных в порядке приоритетности). С чего начнется разработка, какие первые гипотезы вы будете тестировать, каков будет бюджет продукта, состав первых релизов – все это сформулирует владелец продукта. 

Чтобы утвердить состав команды, применяется Feature Team Adoption Map – этот инструмент позволяет наглядно понять, кто потребуется, чтобы реализовать бэклог по функционалу (сколько фронтендеров, бэкендеров, UI/UX дизайнеров и т.д.). После того, как стал понятен профиль специалистов для реализации продукта, можно начинать формировать команду.

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

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

С какими ошибками можно столкнуться при внедрении Scrum и как их избежать

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

1) Одна из глобальных ошибок – это создание карго-культа Scrum на базе уже существующего подразделения. Когда мы формально решили работать по Scrum, но фактически у нас ничего не поменялось на глубинном уровне, кроме названий. Например: возьмем уже существующего руководителя и назовем его владельцем продукта; подумаем, кто может выполнять роль Scrum-мастера из уже существующих специалистов – например, тестировщик. И «начнём работать по Scrum»! То есть формально перенимать структуру фреймворка, повторять его основную канву, но не глубинную суть. 

Это же касается и инструментов. Например, трекер ведения задач из 50-ти колонок с разными этапами работы назвать Scrum-доской. А формат Scrum-доски всегда одинаков: бэклог/спринт-бэклог/в работе/готово. Это сделано для максимально плотной коммуникации. А как только вы нарезаете дополнительные «функциональные колодцы» внутри своей Scrum-команды – это карго-культ. То есть, когда этапы работы нарезаны в зависимости от ролей участников (аналитика, разработка, тестирование, безопасность и т.д.)  – это фундаментально неправильно, при таком подходе вы не реализуете Scrum-процесс. 

Пример Scrum-доски с бэклогом продукта и доской спринта в сервисе Kaiten.

2) Разделение внутри команды, несколько команд. Ведь в основе Scrum лежит кросс-функциональность команды: вы должны все вместе решать каждую задачу на пути реализации продукта. То есть при работе по методологии Scrum вы всей командой сначала проводите аналитику, потом делаете разработку и дизайн, договариваясь между собой, как это всё будет стыковаться. Каждому участнику команды важно взаимодействовать с клиентом и понимать его боли. Не должно быть передачи задач между разными отделами, не должно быть нескольких Scrum-команд из разных подразделений. Scrum-команда кросс-функциональна и замкнута сама на себя для реализации нужд клиента.

3) Ошибки в ходе мероприятий: например, начинать дэйли-митинг с отчета за определенный период – что мы сделали. А по методологии Scrum дэйли-митинг – это точка перепланирования на следующий день, когда команда передоговаривается, что предстоит сделать. 

4) Ошибки во взаимодействии с клиентом. Например, на начальном этапе, когда команда только формируется, не запрашивать обратную связь у клиента – это грубая ошибка. Нужно вести разработку в тесном контакте с клиентом: проводить глубинные интервью, постоянно показывать продукт на различных этапах готовности, чтобы получать обратную связь и корректировать направление работы. 

Есть еще одна распространенная ошибка в коммуникации с клиентом: когда вы проводите ревью спринта и просто на нем отчитываетесь о проделанной работе перед руководителями. Ревью спринта – это точка коммуникации трех видов ролей:

1. команды разработки, которая отвечает за качество;

2. клиента с его потребностями;

3. бизнеса, который инвестирует в команду.

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

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

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

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

7) Отсутствие стабильной постоянной команды. Когда на этапе запуска были одни люди, потом через квартал вы перевели некоторых участников на другой проект – такое по методологии Scrum недопустимо. Команда в Scrum – это константа, без которой невозможен анализ процессов. Когда команда «не сработанная», то теряется производительность и предсказуемость результата. Потому что на сонастройку новых участников команды теряется очень много времени.

8) Ошибки на этапе релизного инкремента. Важно учитывать definition of done — набор критериев, которые позволяют понять, сделано ли то, что было целью разработки. Необходимо на начальном этапе договориться, что такое рабочий продукт и рабочий инкремент – выработать критерии готовности продукта, чтобы клиент мог начать им пользоваться и чтобы его можно было презентовать на рынке. Иначе бывает такое, что команда разработчиков закончила формально работу, а по факту «продукт еще не готов, сыроват, надо его потестировать».

Какие бонусы получит бизнес от применения Scrum?

1. Понимание того, какой продукт нужен рынку. Вы начинаете понимать, какие гипотезы рабочие, как вообще устроен рынок, чтобы эффективно на нем конкурировать. А кто первый вышел с востребованным продуктом, тот «снимает сливки» и получает уже материальные выгоды.

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

3. Быстрый time to market вывода продукта: это время от начала разработки идеи до ее конечной реализации, когда вы продаете её клиенту.