Почему Scrum не надо применять там, где не надо — ограничения и допущения фреймворка

Easy to learn, hard to master

Философия Agile (назовём это так для простоты) вызвала достаточно оживленные обсуждения почти сразу после своего появления в 2001 году, и долгое время Agile ассоциировался в основном с фреймворком Scrum. В общем это актуально и сейчас, т. к. второй по популярности Канбан метод в 2015-2017 вышел из под крыла Agile и стал развивать концепцию Business Agility, а другие подходы, такие как EP, DSDM, FDD, менее распространены.

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

Зачастую менеджеры на старте проекта вынуждены выбирать метод управления из тех, которые сейчас на слуху (чаще всего это Скрам, Канбан, классический PMI / PRINCE2). Но менеджеры часто не обладают достаточным опытом и знаниями о методологиях, их преимуществах и недостатках. А ведь из всех перечисленных подходов Скрам наиболее революционный и бескомпромиссный. Он меняет устоявшиеся принципы работы в компании. Он не принимает существующие структуры и процессы, и жестко устанавливает свои.

О преимуществах, которые может дать работа команды по Скрам, сказано уже очень много. Но во вселенной Agile и Скрам не принято открыто говорить об ограничениях этого подхода. А именно: где вообще можно применять Скрам, а где делать этого не стоит, какие допущения и ограничения есть у этого подхода, каким требованиям должны удовлетворять проект и команды чтобы успешно работать по Скрам, какие есть риски и т. п.
Попробуем разобраться в этом вопросе со следующими оговорками:

• говорим только о Скрам и частично о философии Agile, каковую Скрам представляет. Другие методологии (Kanban, XP, DSDM, FDD, Crystal, etc) не рассматриваем.

• говорим о применимости Скрам в основом в пределах "классической Скрам команды" — 7-9 человек. Масштабируемые гибкие методологии, как то SAFe, LeSS, Nexus и т. п. не рассматриваем, там свои преимущества и недостатки, и Скрам там обычно только на нижнем уровне, выше начинается Канбан.

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

Scrum — это не метод управления проектами

Ключевые слова — "управления проектами". Что такое проект? Это деятельность, связанная с сочетанием конечности (имеет начало и конец, ограниченность ресурсов) и высокой доли неопределенности (включая уникальный результат работы).

Скрам хорошо работает с неопределенностью — короткие итерации со сбором обратной связи, вовлечение заказчика, постоянная рефлексия. Но он ничего не хочет знать о конечности — ограничения сроков, бюджета. Скрам не умеет контролировать попадание в "проектный" треугольник Time-Budget-Scope, фактически он фокусируется только на удовлетворенности заказчика. Даже про контроль состояния команды в Скраме вообще ничего нет — считается что она сама себя умеет организовать и мотивировать.

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

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

Scrum — продуктовый подход в разработке ПО

Несмотря на то, что в руководстве по Скраму авторы пишут:

— есть очень много комплексных проблем, где Скрам применим ограниченно или не применим вовсе. В аутсорсинговой разработке очень часто клиенты хотят контракты по модели Fixed Price — в этом случае использование Скрам очень рискованно. Даже при работе по модели Time&Material клиент должен понимать, какие риски несёт работа по Скрам — отсутствие четких планов по бюджету и длительности проекта, очень высокие требования к специалисту в роли Владельца Продукта (очень часто это сотрудник со стороны заказчика), очень высокая степень вовлеченности заказчика (не все этого хотят и к этому готовы), полная немасштабируемость подхода (хотя для этого есть SAFe, LeSS и т. п.), невозможность работы паралельными связаными потоками работ, достаточно высокие накладные издержки на "планирование и перепланирование", слабый контроль рисков в работе. Скрам плохо подходит для организации работы внутреннних отделов — поддержка, юристы, маркетинг.

Вывод: Скрам хорошо подходит для разработки новых продуктов в области программного обеспечения. И очень ограниченно подходит для аутсорсинговых проектов, тем более не софтверных.

Scrum ничего не знает о дедлайнах или фиксированном бюджете

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

Это делает затруднительным его применение например в Fixed Price проектах, либо проектах с жесткими дедлайнами. Даже при продуктовой разработке конечный заказчик часто хочет знать, когда будет готово и сколько в итоге будет стоить.

Что отвечает Скрам?
"А вам и не нужно это знать"!

По мнению авторов подхода, необходимость точного прогнозирования вытекает из высоких рисков неопределенности — то ли заказчик получит в итоге, что он просил? И Скрам предлагает другое решение — короткие итерации и демо результата (причем, что важно — рабочего инкремента, полезного заказчику уже сейчас). Таким образом заказчик уверен что разработка движется в целом туда, куда ему нужно (максимум потеряем один спринт — поэтому они должны быть как можно короче), и довольно грубо может оценить сколько времени еще осталось на "переваривание" всего имеющегося бэклога.

Тем не менее, далеко не каждого заказчика на вопрос:"Сколько нужно времени / денег?" устроит ответ: "Заранее сказать невозможно, давайте попробуем и посмотрим, как пойдёт".

Вывод: Скрам плох в прогнозировании. В работе с жесткими ограничениями (бюджет, сроки) его применение рискованно.

Scrum — инкрементальный подход (мост по Скраму не построить)

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

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

Пример — разработка электроники. Да, мы можем в конце спринта отгрузить клиенту принципиальную схему, или конструкторскую документацию на печатные платы, или отчет о тепловом моделировании. Насколько полезный для дальнейшей работы фидбэк можно собрать? "Ну мы посмотрели, вроде всё ок"? Всё Ок или не Ок в любом случае можно понять, только получив готовое устройство на руки и проведя тестирование. Поэтому даже если внешне это может выглядеть как Скрам, по сути таковым оно часто не является, если нет ценного, полезного инкремента в каждом спринте.

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

Scrum — командный подход

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

Чтобы Скрам заработал, нужна высокая степень вовлечённости всех участников команды — ВП, СМ и разработчиков. Ответственность за результат коллективная, поэтому управленческие решения принимаются совместно всей Скрам-командой, а не каким-то одним руководителем или менеджером.

Аналогичным образом все встречи в Скраме рассчитаны на активное вовлечение всех участников команды и коллективное принятие решений. Каждая встреча Scrum нацелена на одно из двух:

• координация работы команды (дейли встречи, планирование, обзор спринта),

• развитие командного взаимодействия и взаимопомощи, опыта или навыков команды (ретроспектива)

Руковоство по Скраму прямо говорит, что для успешной работы вам нужна сплоченная, самоорганизованная и вовлеченная в работу команда. Команда (!) а не просто группа разработчиков, объединённая одним проектом. Чем отличается команда от рабочей группы можно легко найти в гугле, например https://asana.com/ru/resources/group-vs-team

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

Все метрики в Скраме тоже собираются только в отношении команды, никакого персонального perfomance или velocity. И поскольку в реальной жизни в команде все время происходят какие-то изменения — увольнения / найм новых сотрудников, отпуска, отгулы, болезни и т. д., то основной показатель работы velocity (мощность команды, какой объём работы в условных story points она может "съесть" за один спринт) — тоже редко остается стабильным в команде из 7-9 человек. Это к вопросу выше о планировании в Скраме.

Отдельный вопрос — о лентяях и "токсичных" людях в команде. Предполагается что команда сама вытолкнет таких паразитирующих личностей из коллектива, что на практике бывает крайне редко, либо может занять продолжительное время (вспоминаем модель Брюса Такмана и 5 пороков команды Патрика Ленсиони). Нужен менеджер, который будет разруливать такие вопросы, а никаких менеджеров в Скраме, как мы помним, нет.

Вывод: Скрам требует наличия сплоченной самоорганизованной команды. Нужно заранее продумать, есть ли она, или как её планируется создать.

Scrum опирается на кросс-функциональную команду

Кросс-фунциональная — означает, что

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

Что на практике это должно значить: каждый член команды должен уметь и бизнес-анализ провести, и дизайн нарисовать, и код написать, и потестить; или команда должна включать в себя всех необходимых специалистов — руководство по Скраму ответа на даёт. Но такие мульти-функциональные специалисты если и есть, то мне никогда не встречались. Действительно кросс-функциональная команда — редкость. В жизни бывает что команда состоит только из разработчиков, а QA / UI/UX / DevOps — это другие команды, или структурные «подкоманды», которые в Скраме делать нельзя.

Включение же в команду всех ролей — BA, UI/UX, Dev, QA — тоже имеет определенные особенности работы. Все они не могут одновременно работать над одними и теми же задачами, чаще всего последовательность — BA -> UI -> Dev -> QA. И сложно организовать работу всех внутри спринта так, чтобы Скрам-команда не разбилась на несколько подкоманд внутри, или спринты не разделилиь на паралельные потоки для бизнес-анализа, разработки, тестирования, что тоже противоречит идее Скрама.

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

Вывод: Перед началом проекта проверить действительно ли кросс-функциональна команда, либо найти способ обойти это (напр. замена QA автотестами, вовлеченность команды в планирование с PO — аналитик не нужен).

В Scrum достаточно высокие накладные расходы на "церемонии"

Главный принцип Скрама — работа как можно более короткими итерациями (спринтами) с поставкой и сбором обратной связи от заказчика. Короткие спринты уменьшают потери в случае разработки не того или не так, как нужно клиенту. Но есть и тёмная сторона работы короткими (например недельными) спринтами. При спринтах длительностью в одну неделю слишком высокие накладные расходы на церемонии: планирование + дейли + демо + ретро + бэклог груминг = 1.65 дня при недельном спринте — почти 30% всего рабочего времени!. При двухнедельном спринте накладные расходы составляют около 18ч с учетом работ по уточнению бэклога. Возможно, это не совсем то, что вы ожидали увидеть, когда читали что в Скраме "нет долгих митингов по планированию".

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

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

Скрам by design может работать только на уровне небольшой команды — как правило, 7–9 человек максимум. Также нет смысла пытаться работать по Скрам, когда у вас в команде только 1-2 человека (Владелец продукта и Скрам-мастер не учитываются при определении размера команды), и больше никто не задействован в работе над продуктом. Скрам в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.

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

Чтобы преодолеть эти трудности на большом масштабе, приходится применять "общую" фасилитацию, проводить громоздкие и долгие встречи (например, Big Room Planning в SAFe), чтобы все Скрам-команды успели обсудить и спланировать совместную работу, синхронизировать дальнейшие цели и контекст работы.

Так как у каждой команды своя собственная Скрам-доска и свой бэклог (в идеале PBI в бэклоге должны быть сформулированы по приницпу INVEST, то есть в т.ч. независимы), то в процессе общей работы над частями большого продукта нужны регулярные синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Скрам-мастера́ или Владельцы Продуктов).

Вывод: при работе нескольких команд над одним продуктом Скрам как таковой уже не подходит, применяются другие подходы - SAFe, LeSS.

Сторонники Scrum скупы на критику

В Agile-вселенной вам никогда не скажут «Здесь Скрам подходит, здесь — нет». Там обычно пытаются натянуть сову на глобус и как-то прилепить Скрам всегда и везде. Во многом это обусловлено чрезмерным хайпом на тему гибких методологий, приведшим в индустрию множество людей со стороны, без технического бэкграунда, без опыта в разработке ПО, да и без нужных софт-скиллов зачастую тоже. И явно заинтересованных в продвижении именно этого подхода.

На Западе Agile–коуч, как правило, специалист с 15-20-летним опытом работы в области разработки ПО или управления разработкой, с большой "насмотренностью" и устойчивостью к повторениям "ошибок выжившего".

На нашем рынке — обычно позитивный молодой человек / девушка лет 25-28 плюс минус, чаще всего с гуманитарным образованием и недельным курсом Скрам-мастера в багаже. Эти люди понимают, что востребованы они только до тех пор, пока популярен Скрам на рынке.

Вывод: придется во всем разбираться самому, на помощь со стороны сильно не надейтесь.

Scrum побуждает к привлечению внешних специалистов — Скрам-мастеров и Agile коучей

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

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

Всё это слишком напоминает классическую воронку инфобиза:
Этап 1 — низкий порог входа, простые понятные принципы/инструменты.
Этап 2 — короткий, недорогой тренинг, где расскажут, что делать.
А вот КАК делать, вам расскажут на Этапе 3 — весьма дорогостоящий платный консультант, на этом этапе основные деньги и делаются.

Вывод: у Agile коуча всегда много вопросов и нет ответов.

Высокие требования в Scrum к Владельцу Продукта (Product Owner)

Скрам не предусматривает достаточный по времени этап сбора и анализа требований. Откуда они возьмутся, как правильно оценить их взаимосвязь, влияние на бизнес, выставить приоритет — ответов Скрам не даёт. Для всего этого есть роль Владельца продукта, который должен одновременно работать с заказчиком и командой, сочетать в себе аналитика, представителя бизнеса и маркетолога. Много вы встречали людей с таким набором компетенций?

Повезёт, если это будет представитель со стороны заказчика. Но это своего рода читерство — единственную роль с ответственностью за результат мы передали заказчику. Заказчик редко и ТЗ внятное самостоятельно написать может, а тут полная ответственность за продукт.

Привлечь с рынка готового специалиста тоже не получится — ему потребуется довольно длительное время чтобы понять бизнес клиента и ваши процессы.

Вывод: без толкового Владельца продукта процесс не полетит. А найти такового очень непросто.

Резюмируем сказанное

• Скрам — не для управления проектами. Многие аспекты управления остаются вне его рамок. Это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов.

• Основные преимущества Скрама проявляются в разработке инновационных продуктов на быстро меняющемся рынке.

• Скрам плохо подходит для разработки с ограничениями по срокам или бюджету. Он вообще довольно плох в планировании.

• Скрам подходит только там, где возможна поставка ценности заказчику небольшими работающими полезными инкрементами.

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

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

• Несмотря на то, что долгосрочного планирования в Скраме нет, в реальности при коротких спринтах (одна-две недели) могут быть довольно высокие накладные расходы на обязательные церемонии.

• Скрам работает только в командах 3-9 человек, он не масштабируется ни вниз ни вверх.

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

• Подход неявно подталкивает к привлечению внешних (довольно дорогостоящих) консультантов, если сходу не получилось самостоятельно все запустить. При этом такие консультанты чаще всего не отвечают за результат — добро пожаловать в мир коучинга.

• Скрам предъявляет высокие требования к роли Владельца продукта. Со стороны заказчика такие бывают редко, просто нанять на рынке тоже не получится.

Чтобы Scrum начал приносить пользу, нужно удовлетворять довольно объемному списку предусловий:

• Выделить Владельца продукта — специального представителя бизнеса, который:

  • будет наделен полномочиями для самостоятельного принятия решений о том, как должен выглядеть продукт, 

  • несет ответственность за наполнение продукта действительно ценным для клиента функционалом

  • будет тесно взаимодействовать с командой разработки

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

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

• При необходимости — выделить Скрам-команде свой контур инфраструктуры, чтобы они могли самостоятельно делать end-to-end разработку.

• Обучить основам работы по Скрам всех участников Скрам-команды, заказчика и всё окружение, в котором работает команда.