5 ситуаций, когда Scrum не нужен, и что с этим делать

Мы написали эту статью вместе с Олегом Свирским, Senior Product Manager в Vimeo. Вот его фейсбук.

Продакт-менеджер Алекс сходил на конференцию по Scrum. Теперь он не может жить без заряда дейли стендапов и осознанности ретроспективы. Надо срочно внедрить Scrum у себя в команде! 

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

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

После этой статьи будет полезно прочитать о том, как использовать фреймворки.

Что такое этот ваш Scrum

Scrum — подход к разработке, в котором команды работают по спринтам от 1 до 4 недель. Команды состоят из 5-9 человек и самостоятельно распределяют задачи между собой. 

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

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

Но не всем командам удобно работать по Scrum. Разберем пять таких ситуаций.

Марк и дизайнеры

Ситуация:

Марк пришел продактом в новую компанию. На предыдущем месте его команда успешно работала по Scrum. Поэтому он захотел повторить этот опыт с новыми коллегами. 

Марк собрал команды и рассказал, что теперь все будут работать по спринтам. Начать нужно с планирования задач на текущую неделю. 

Решение:

В этой ситуации поможет фреймворк Kanban. На Kanban доске команда будет видеть, сколько задач нужно сделать («To-do»), сколько выполнено («Done»), а сколько находится в работе («Doing»). 

Kanban даст больше гибкости в управлении потоком задач. Разработчики будут добавлять свои задания в колонку «To-do». А дизайнеры будут выполнять одну задачу за другой. В отличие от Scrum, они могут принимать сколько угодно запросов от других команд.

Но тут важно не забывать про WIP (Work in Progress). Это ограничение на число задач, которые может одновременно делать один сотрудник. Дизайнеры Крис и Майк могут брать каждый раз по одной задаче. К следующей они приступят, когда закончат делать текущую. Такой подход поможет им не терять фокус, а разработчикам — эффективно использовать ограниченные ресурсы.

Попробуйте решить одно из заданий по этой теме из нашего нового курса «Взаимодействие с командой разработки».

Задание

Мэри и сложная задача

Ситуация:

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

Решение:

Каждый участник Scrum-команды во время спринта делает свой кусок работы. Но бывает так, что программист может столкнуться со сложной задачей, и для ее решения понадобится еще чья-то помощь. Так появилось парное программирование.

Пара состоит из двух человек: драйвер и навигатор. Драйвер пишет код, а навигатор проверяет каждую строчку кода и говорит драйверу, что делать дальше. 

Спустя некоторое время программисты меняются ролями. Драйверу может прийти идея о том, как улучшить код. Тогда он становится навигатором и направляет своего напарника.

Адам и масштабный проект

Ситуация:

Адаму поступил запрос от заказчика внедрить ERP-систему в крупную государственную компанию. Для реализации этого проекта нужно привлечь все команды разработчиков, которые есть в компании.

Предстоит разработка нового продукта, поэтому вы решаете организовать работу по Scrum и проводите спринт-планирование.

Решение:

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

Здесь поможет подход SAFe  (The Scaled Agile Framework). Он предлагает инструменты для управления масштабными проектами, где участвует много команд. 

На разработку каждого инкремента уходит четыре спринта или около двух месяцев. Также существует пятый спринт. Он называется HIP-спринтом. Так как команды работали над большим проектом, им нужно время, чтобы разобраться с техническим долгом и провести ретроспективу. 

Задание

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

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

Как в этом случае вернуть мотивацию разработчикам и улучшить качество фич?

SAFe во многом похож на Scrum, но занимает больше времени. А в процессах планирования и разработки участвует больше людей, контролирующих работу команд.

Лиза и не самоорганизованные команды

Ситуация:

В компании Лизы три команды разработчиков работают вместе над созданием модуля по аналитике: 

• группа #1 отвечает за базы данных, 

• группа #2 делает коннектор, который передает данные из баз в модуль, 

• группа #3 строит графики и диаграммы на основе полученных данных. 

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

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

Решение:

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

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

Посмотрите, как улучшилось время на подготовку к релизам после того, как в команде появился релиз-менеджер. Похожих результатов добилась у себя и компания «Додо Пицца».

Алекс и компания, где и так все работает

Ситуация:

Продакт-менеджер Алекс предложил руководству компании начать работать по Scrum. До этого Алекс уже внедрял Scrum и успешно работал по нему. Сейчас он хочет использовать этот подход в текущей команде.

Решение:

Перед тем, как внедрять Scrum в компанию, подумайте: а может команда и так отлично справляется. Если все хорошо, обратите внимание на микровещи, которые можно улучшить с помощью Scrum. 

Например, можно внедрить обязательные короткие ежедневные собрания, на которых будут обсуждаться текущие задачи. Такие встречи приучат команду к постоянному обмену фидбеком. 

Но не пытайтесь начинать резко менять уже существующие бизнес-процессы, которые и так хорошо работают. Иначе нанесете убытки своей компании.

Резюмируем

Scrum может принести пользу вашей команде, если внедрять его с умом. Изучите, какие задачи помогает решать этот фреймворк. Проанализируйте задачи вашей команды и сравните с тем, что предлагает Scrum. 

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