В 2010 году вышло первое руководство по Scrum, кардинально изменившее положение дел в мире разработок. То, что задумывалось как простой фреймворк, стало общепринятым рабочим процессом в большинстве компаний, занимающихся цифровыми технологиями, по всему миру. Рынок встретил Scrum с распростертыми объятиями, создав тысячи вакансий мастеров и владельцев продукта Scrum. Его так называемые “роли” развились в полноценные профессии для многих людей.
Большинство компаний восприняли Scrum как волшебное средство от всех проблем, считая его гарантией успеха. Однако лишь немногим из них удалось максимально плодотворно использовать потенциал этой методики. Такие компании преуспели в бизнесе, а вот другие, менее успешные, подвергли Scrum жесткой критике.
Компании, не достигающие желаемых результатов с помощью Scrum, ищут альтернативные решения. Как правило, сбой происходит при масштабировании: производительность падает, зависимости растут, а команды пребывают в состоянии полной растерянности. Ответственные лица не доверяют Scrum в обеспечении требуемого контроля и жаждут более надежных структур. Чаша весов склоняется в сторону старой каскадной модели разработки, а решением становятся фреймворки по типу Scaled Agile Framework (SAFe). Компании хотят быть гибкими и мобильными, но при этом не могут преодолеть изживший себя командный стиль управления и контроля.
В настоящее время Scrum сталкивается с еще большим сопротивлением, чем когда либо. Повсеместно компании отвергают данный подход и стремятся к чему-то иному. Зачастую из уст специалистов, ответственных за принятие решений, можно услышать такие высказывания:
- В нашем случае он не работает.
- Scrum подобен политикам: они обещают тебе рай, а в итоге ты оказываешься в аду.
- Он подходит только для взаимодействия небольших команд.
- Scrum перегружает разработчиков многочисленными совещаниями.
Далее я поделюсь своими размышлениями на тему того, почему время Scrum близится к закату.
Scrum — это не волшебная таблетка
На протяжении многих десятилетий компании разрабатывали ПО, следуя каскадной модели. Многие специалисты, претворявшие ее в жизнь, испытывали похожие затруднения: разрозненные команды, отсутствие сотрудничества, минимальное участие клиента и т. д. Несмотря на изнурительный процесс, результат зачастую был неудовлетворительным — ошеломленным клиентам предлагалось решение, которое никак не решало их проблемы. Традиционная каскадная модель не приводила компании к успеху, поэтому нужно было срочно что-то менять. В этот момент и появился Scrum.
В чем же была проблема? В самом процессе или в чем-то другом? Перед тем как ответить, представьте футбольную команду, которая на протяжении десятилетий не выигрывала чемпионат. И вот во главе нее становится новый тренер, который совместно с игроками реализует концепцию тотального футбола — именно так сборная Нидерландов поразила весь мир в 70-х годах. Но несмотря на тренерский оптимизм, результат остался таким же плачевным, как и прежде.
Может ли команда побеждать, изменив лишь тактическую схему? Вероятно, нет, поскольку здесь имеют значение более важные аспекты, чем стиль игры, например изменение образа мышления, поддержка руководства и наличие нужных игроков.
Многие компании заменили каскадную модель на Scrum, не урегулировав свои процессуальные дисфункции. Первое распространенное заблуждение состоит в понимании Scrum не как фреймворка, а как процесса. На самом деле он является незавершенным проектом. Ни одна компания не преуспеет, если будет руководствоваться лишь этим методом. Например, техника управления продуктом не является частью Scrum, при этом она необходима для достижения эффективных результатов.
Не имеет значения, какой процесс разработки применяет компания, он никогда не будет безупречным при наличии неразрешенных дисфункций. Перечислим некоторые из них:
- директивы и контроль;
- нечеткие цели;
- иерархичный принцип расстановки приоритетов;
- микроменеджмент.
Применение этого фреймворка неминуемо закончится неудачей для тех компаний, которые не урегулировали свои внутренние дисфункции, а виновным все равно окажется Scrum.
Scrum не предназначен для организаций, испытывающих страх перемен. Успешное воплощение этого метода напрямую зависит от гибкости мышления. Вот почему многие консервативные компании сделали выбор в пользу SAFe, жестко регламентированного фреймворка, который не имеет никакого отношения к Scrum.
Опять же, SAFe и Scrum преследует разные цели. По большей части SAFe — это фреймворк, ориентированный на доставку продукта. Scrum решает сложные задачи, нацеливаясь на достижение максимально высокого качества. В этом состоит их важное отличие. SAFe больше соответствует традиционным подходам и структурам компании. Он более безопасен для топ-менеджмента, но при этом не предоставляет ни наилучшей гибкости, ни продукты высочайшего качества.
При взгляде на SAFe всегда становится страшно из-за трудоемкого процесса. Такой подход сложно назвать гибким. Например, кто за что отвечает? Прежде чем понять динамику взаимодействия с клиентом, сначала придется потратить какое-то время просто на поиск нужных данных. И как вообще язык поворачивается называть этот подход гибким?
Почему Scum на грани исчезновения?
Гибкий фреймворк Scrum широко применяется разными компаниями по всему миру, но вот способы его воплощения очень сильно отличаются. Степень готовности организаций к изменениям определяет то, насколько успешными или неудачными будут предпринятые попытки. Если реализация Scrum касается только выполнения, то результаты ничем не будут отличаться от предыдущего сценария. Но осмелившись пошатнуть свой привычный уклад, компания делает первый шаг к успеху.
В чем же состоит самый распространенный способ реализации Scrum? Думаю, вы в курсе того, как это происходит. Топ-менеджмент неохотно идет на кардинальные изменения устоявшегося режима разработки, если не уверен, что они приведут к существенному повышению качества.
Топ-менеджмент убежден, что по-настоящему самоуправляемые команды представляют для них опасность. Вот почему Scrum не находит своего дальнейшего развития.
Топ-менеджмент не готов поддерживать команды Scrum из-за опасения утратить контроль, вследствие чего выбирает самый короткий путь. Сначала изменения затрагивают процесс выполнения, а затем при подтверждении эффективности Scrum меняется и весь подход к разработке. Однако такой способ реализации не сработает, и результат разочарует всех. Если Scrum применяется только для выполнения, то искажается сама суть ролей. Поделюсь с вами некоторыми наблюдениями.
Владелец продукта
Владельцы продуктов будут уподобляться официантам до тех пор, пока не возьмут на себя ответственность за расстановку приоритетов. Они принимают заказы, рекомендуют гарнир и направляют их на кухню — удручающее занятие. Единственная их задача заключается в управлении ожиданиями заинтересованных сторон и обеспечение взаимодействия между разработчиками.
Трансформации роли владельца продукта Scrum стали настолько привычным делом, что зачастую сложно понять, почему кто-то так называется. Оглядываясь на свою профессиональную деятельность, можно сказать, что я в какой-то степени исполнял роль владельца продукта, но при этом у меня никогда не было всех полномочий, предусмотренных в руководстве по Scrum. В связи с этим возникает вопрос, существует ли вообще в корпоративном мире владелец продукта Scrum?
Разработчики
В теории сами разработчики решают, как им выполнять свою работу. Они несут полную ответственность за выбор способа реализации и применяемого комплекта технологий. Опять таки — на практике я этого не видел. Как правило, есть технический директор (CTO), техлид или кто-нибудь еще, который не только диктует свои условия, но и дотошно контролирует разработчиков.
Scrum предполагает независимость разработчиков, но на самом ли деле они ей обладают? Не думаю. К сожалению, большинство из них получают четко определенные решения для реализации, и редко кому предоставляется возможность работать над задачами без оглядки на конкретные сроки исполнения.
Разработчик Scrum превращается в такого же мифического персонажа, как и владелец продукта. В реальности чаще всего они становятся узниками на фабрике по созданию функциональностей.
Мастер Scrum
Чаще всего в Scrum пренебрегают ролью мастера. Она просто отсутствует в команде, поскольку компании рассматривают оплату этой должности как бессмысленную трату денег. Но даже являясь участниками команды, мастера часто оказываются беспомощными, поскольку не могут претворять необходимые изменения на благо Scrum.
В этом отношении мастер Scrum ничем не отличается от других должностей. И вряд ли вы найдете специалиста такого плана, полномочия которого точно бы совпадали с описанными в руководстве по Scrum.
Выживет ли Scrum?
Учитывая все перечисленные трансформации ролей, многие высококвалифицированные специалисты устали от Scrum и утратили в него веру. Они стремятся найти другие подходы и ищут возможности для экспериментов с разными фреймворками.
Неготовность топ-менеджмента к изменениям вынуждает команды применять упрощенную версию Scrum, которая оборачивается неудовлетворительными результатами. Череда неудачных решений и ошибочных представлений может погубить Scrum, и тогда топ-менеджмент вернется на круги своя: к предписаниям и контролю. По этой причине SAFe, негласный агент каскадной разработки, оказывается в центре внимания.
Как избежать краха Scrum?
Scrum поможет преуспеть только тем компаниям, которые захотят измениться полностью. Этот метод требует иного видения, и какой бы гибкий фреймворк не применяли бы компании, их будут преследовать неудачи до тех пор, пока они не изменят свой образ мышления. Но надежда все-таки есть, поскольку многие настроены двигаться в этом направлении. И вот несколько тому подтверждений.
- Топ-менеджмент осознает необходимость в управлении продуктом, и руководитель по продукту становится частью исполнительской команды.
- Перспективный план разрабатывается на основе методологии OKR (Objectives and Key Results — «цели и ключевые результаты»), согласно которой топ-менеджмент определяет цели, а команды Scrum — результаты.
- Команды вправе экспериментировать с разными альтернативными решениями для получения ключевых результатов.
- Утверждается исследование продукта. Ответственные лица знают, насколько важно уделять достаточно времени на поиск проблем, содержащих в себе потенциально плодотворные решения.
Речь идет не об улучшении Scrum, а об обеспечении высокого качества.
Читайте также:
- Мы снова написали самый быстрый JS-фреймворк UI
- 3 совета, как стать мастером Йода по JavaScript
- Обзор техник кэширования в React
Читайте нас в Telegram, VK и Дзен
Перевод статьи David Pereira: Is Scrum Dying?
