Обратная сторона SCRUM

Не хватает гибкости? Нужен Scrum. Нужно побыстрее выпустить продукт? Нужен Scrum. Нужна самоорганизованная команда? Работай по Scrum. Кажется, что он стал слишком популярным, но при этом не везде работает так, как должна. Почему так — пообщались с сертифицированным Scrum-мастером Дмитрием Ирешевым и узнали, какие неприятные проблемы таит в себе этот фреймворк.

Парадокс Scrum: почему он стал настолько популярным, но при этом редко встречается

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

С появлением Agile традиционный Waterfall стал мифическим врагом, которым его показывали организации вроде Agile Alliance. Каскадная модель превратилась в символ всего неэффективного и неповоротливого, а противопоставление гибким подходам сделали мощным маркетинговым нарративом. Это привело к тому, что появилась целая индустрия, которая активно поддерживала интерес к Scrum, пока популяризаторы фреймворка зарабатывали на курсах, тренингах и сертификациях по типу Certified Scrum Master (CSM) или Professional Scrum Master (PSM).

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

Со временем фреймворк Scrum стал настолько популярным, что в какой-то момент в вакансиях стали указывать использование Scrum как плюс работы в компании:

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

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

Из-за непонимания принципов Scrum и возникают все темные пятна на его репутации.

Scrum стал универсальным, и в этом его проблема

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

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

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

Scrum’ом могут оправдывать неудачные решения

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

«Чаще всего сталкиваюсь с тем, что команды делают продукт или сервис, который невозможно масштабировать. Его создание объясняют тем, что это MVP. В таких случаях приходится переписывать значительную часть кода, а это потеря не только денег, но и времени. Если конкуренты не делают таких ошибок, они поставляют новый функционал быстрее, а вы вынуждены стоять на месте», — Дмитрий Ирешев.

Отсутствие бюрократии при работе по Scrum — это заблуждение 

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

Сначала появляются проблемы с ежедневными дейликами. Вместо 15-минутной встречи, на которой команда рассказывает про результаты работы, следующие шаги и сложности, начинаются обсуждения других задач или видения проекта. В итоге стендапы затягиваются. И дело не ограничивается только ими, ведь параллельно начинаются дополнительные «созвоны на 5 минут» во время разработки, «созвоны на 5 минут» по итогу созвона-ретроспективы и созвоны-уточнения по итогу стендапа.

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

Хотя даже при правильной работе в рамках Scrum бюрократические процессы все равно будут:

«Порядка 20% всего времени команда тратит на синхронизацию. В реальности даже больше за счет кросс-командных взаимодействий, которые не учитываются во фреймворке. Но есть зрелые команды, которые давно используют Scrum, четко знают свои сильные и слабые стороны. Им допускается, к примеру, пропускать ретроспективы. Это лучше, чем тратить время на формальности», — Дмитрий Ирешев.

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

«Спринты включают в себя планирование спринта, ежедневные проверки, работу по разработке, обзор спринта, ретроспективу спринта и столько других встреч, сколько менеджер сочтет необходимым».

В компаниях не понимают роль Scrum-мастера. А еще не все Scrum-мастера понимают свои задачи

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

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

«Вероятно, я никогда не видел опытного Scrum Master в работе. Со стороны это выглядело следующим образом: “менеджер команды разработки” — это такой Scrum Master, на которого Product Owner делегировал часть своих обязанностей по работе с командой. Он проводит встречи, пишет резюме встреч и поднимает настроение команде», — Дмитрий Ирешев.

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

• отправку всевозможных отчетов руководству;

• ретроспективы ради ретроспектив;

• микроменеджмент.

«В моей же картине мира, Scrum Master должен быть, как Джон Сильвер из Острова Сокровищ — он не был капитаном, но сам Флинт (Product Owner) его боялся. Product Owner фокусируется на стратегии развития продукта, а Scrum Master организует ежедневную работу команды», — Дмитрий Ирешев.

Сложно собрать каноническую Scrum-команду

The Scrum Guide показывает, что команда — самостоятельная единица. В гайде 2017 года была самоорганизующаяся команда разработчиков, а в 2020 году это определение заменили на самоуправляемую Scrum Team. И всегда в команде участники сами выбирают, кто и за что отвечает.

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

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

И сложно сделать так, чтобы команда работала слаженно

Если все же получилось собрать сильных специалистов, то возможна еще одна проблема — команда не работает как единое целое. Бывает, это происходит из-за характера задач. Например, когда в спринт попадает куча несвязанных работ, и команде сложно определить общую цель и направить усилия в одно русло.

Иногда это вопрос культуры: люди сосредотачиваются только на «своих» задачах и не думают о коллективном результате. Выстроить процессы становится непросто, и чем больше команда и продукт, тем чаще возникают такие ситуации.

Исправить сложности будет проще, если повысить прозрачность процессов и распределения работ. Команда, как минимум, будет видеть общий пул задач и понимать свою роль. А если в Scrum Team больше 10 участников, будет понятно, можно ли разделить одну большую команду на две или больше, чтобы у каждой была своя цель. 

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

Еще причина может быть в частых вмешательствах или недовольстве заказчика. На фоне этого с каждым спринтом у команды становится все меньше мотивации и команда работает менее слаженно. В этом случае ответственность стоит взять владельцу продукта:

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

Все минусы не делают Scrum плохой методологией

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

«Если у вас не получилось внедрить Scrum или любой другой подход, то это вина того, кто его внедрял. Необходимо проанализировать, чего не хватило: поддержки со стороны топ-менеджеров, отсутствие контроля или саботаж на местах, после этого сделать выводы и пробовать еще раз. Дело в том, что если у вас все хорошо, то Scrum и любой другой подход вам не нужен. Внедрение разных практик — это реакция топ-менеджмента на существующие проблемы в компании», — Дмитрий Ирешев.

Проще говоря, Scrum, как и любая другая практика, принесет только пользу, если на старте придерживаться ее на 100%, а набравшись опыта адаптировать под контекст компании.