Почему мы следуем процессу, который называем “Scrum”, но при этом никто не следует процессу, который сам Scrum Guide определяет как Scrum?

Этот повсеместно распространённый “Scrum” стал инструментом угнетающего микроменеджмента. Всё сводится к сторипойнтам и velocity. Он вызывает крайнее раздражение у разработчиков, дизайнеров, продакт-менеджеров и даже у менеджеров среднего звена. Больше всего раздражает то, что решения всех этих проблем давно известны и изложены в Scrum Guide.

Scrum Guide довольно чётко определяет, что является Scrum, а что нет:

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

Лишь немногие из нас работали в настоящей Scrum-команде (в том смысле, который транслирует Scrum Guide), но почти все сталкивались с карго-культом Scrum.

Следовать Scrum — это не самоцель. Важна гибкость (“agility”), а Scrum — всего лишь один из способов её достижения. Однако почти каждая компания при внедрении Scrum изначально убирает из него критически важные элементы, без которых он просто не может работать. Дело не в слепом следовании Scrum Guide, а в понимании того, как он устроен. Именно поэтому мы прибегаем к метафоре «карго-культ» — потому что на деле происходит копирование внешнего облика системы, но при этом исключаются ключевые механизмы, которые делают её работоспособной.

Это поднимает более глубокий вопрос: почему мы следуем процессу, который называем Scrum, но при этом никто не следует процессу, который Scrum Guide определяет как Scrum?

В Agile-трансформациях возникает множество проблем, но чаще всего на первый план выходят две идеи, которые содержит в себе Scrum Guide:

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

и

«Вся Scrum-команда несёт ответственность за создание ценного и полезного инкремента в каждом спринте».

Инкремент

Хотя приведённые выше цитаты выглядят разрозненными, в действительности вторая часть тесно связана с первой:

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

• Вся Scrum-команда несёт ответственность за создание ценного и полезного инкремента в каждом спринте.

Для создания ценного и полезного инкремента в каждом спринте необходима кросс-функциональная команда. Если же команды разделены по функциям, то, например, UX-команда должна работать заранее, ещё до того, как к процессу подключится команда разработки (как рекомендует Nielsen Norman Group). Однако это означает, что UX-команда не выпускает инкремент в каждом спринте — она лишь создаёт элементы бэклога для разработчиков. В результате разработчикам также становится сложнее выпускать полноценный инкремент.

Если мы не можем использовать работающее программное обеспечение в качестве основного показателя прогресса, у нас не остаётся выбора, кроме как полагаться на оценки. Именно так Scrum превращается в систему, ориентированную на сторипойнты и velocity, а не на пользователей и ценность продукта. Однако первое же из двенадцати принципов Манифеста Agile гласит:

«Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения».

Это значит, что если вы не выпускаете ценный продукт для пользователей на постоянной основе, то всё, что вы делаете, не является agile. Scrum-команда, которая не создаёт полезный инкремент в каждом спринте, не является Scrum-командой.

В своей статье «Тёмный Scrum» Рон Джеффрис (один из авторов Agile-манифеста) подчёркивает ключевую роль инкремента и объясняет, как отсутствие инкремента порождает тот самый «угнетающий Scrum», который все мы так не любим:

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

Почему мы этого не делаем? Причины кроются в нескольких факторах:

1. Организационные барьеры. Мы разделены на функциональные команды, из-за чего создание кросс-функциональных команд становится логистически (а иногда и политически) сложной, если не невозможной задачей.

2. Сложность вертикального разбиения задач. Делить большой проект на вертикальные срезы действительно трудно.

3. Качество инкремента. Даже если команды организованы правильно, как пишет Рон Джеффрис в той же статье:
   «Инкремент должен по-настоящему работать. Он должен быть протестирован, интегрирован, готов к выпуску и содержать все запланированные элементы бэклога».

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

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

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

Самоуправляемая команда

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

Один из ключевых вопросов, возникающих в процессе Agile-трансформации — какую роль играют менеджеры в Scrum. Должны ли они становиться Scrum-мастерами? Или, может быть, владельцами продукта?

На самом деле Scrum Guide даёт чёткий ответ на этот вопрос:

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

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

Менеджеры видят в Agile экзистенциальную угрозу, поэтому часто (осознанно или неосознанно) сопротивляются его внедрению. Они просто ищут своё место в новой системе и подстраивают процесс под себя. Более того, они искренне могут верить, что облегчают жизнь разработчикам, беря на себя часть управленческих задач.

Но, как пишет Майк Кон:

«Agile — это микроменеджмент, но это микроменеджмент, который команда делает сама и в своих интересах».

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

Ален Холуб подчёркивает: если Agile-трансформация приведёт к тому, что менеджеры останутся без работы, она обречена на провал.

Чтобы трансформация была успешной, необходимо дать этим людям будущее. В грамотной компании менеджерам предложили бы, например:

• Стать Scrum-мастерами, владельцами продукта или полноценными членами команды — в зависимости от их навыков и интересов.

• Пройти обучение, если для новой роли нужны дополнительные знания.

• В случае, если человек не хочет становиться частью новой Agile-команды, помочь ему найти более подходящую работу в другом месте и поддержать выплатами.

Если же компания не заботится о судьбе менеджеров, они становятся главной преградой на пути к гибкости. Они защищают свои позиции и борются за выживание, вставляя Agile-командам палки в колёса.

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

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

Scrum переводит организации на этот принцип, так как определяет Scrum-команды как самоуправляемые.

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

Если в компании сохраняется командно-контрольная система, которая требует одобрения каждого шага сверху, то Scrum работать не будет. Такой процесс затягивает цикл инспекции и адаптации, разрушая гибкость.

Если кто-то управляет вашей работой, значит, ваша команда — не самоуправляемая. А если команда не самоуправляемая, то, согласно Scrum Guide, это уже не Scrum.

Эффект «Обезьяньей лапы» в Scrum

Согласно результатам исследования, проведённого платформой Parabol, компании планируют внедрять гибкие методологии по следующим причинам:

1. Более быстрая поставка ценности клиентам (83%)

2. Рост продуктивности (76%)

3. Прозрачность, предсказуемость и управляемость (70%)

4. Повышение эффективности (69%)

5. Улучшение способов организации работы (68%)

Пункты №1, №2 и №4 тесно связаны между собой — хотя и не синонимы. Переосмысление качества совместной работы всё же попадает в топ-5. В этом пробеле видно предположение, что с бизнесом всё в порядке — нужно просто заставить разработчиков делать больше.

Scrum воспринимается не как инструмент организационной трансформации, а как способ увеличения объёма работы команды.

• Если нужен Scrum-мастер — пусть им будет менеджер.

• Если нужен владелец продукта — пусть эту роль возьмёт на себя менеджер проекта.

• Внедрить Scrum? Легко! Достаточно настроить Jira, делать ревью спринтов и проводить дейли.

На этом трансформация заканчивается.

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

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

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

На практике это обычно означает усиленный фокус на сторипойнтах, velocity (скорости выполнения задач) и других метриках, а также введение ограничений, чтобы обеспечить стабильный уровень производительности. Здесь вступает в действие закон Гудхарта: когда показатель становится целью, он перестаёт быть хорошим показателем. Команды учатся гнаться за метриками, а не за ценностью, при этом не выпускают больше полезного софта, чем раньше.

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

Два самых часто игнорируемых пункта в Scrum Guide — это именно те элементы, которые требуют изменений на уровне всей организации. 

Гибкость за пределами Scrum

Надеюсь, Scrum Alliance не отзовёт у меня сертификацию за эти слова, но мне кажется, что Scrum исчерпал свою полезность.

Сердцем Scrum всегда был цикл инспекции и адаптации. Как постоянно напоминает Дэйв Томас (один из авторов Agile Manifesto), базовый алгоритм гибкости выглядит так:

1. Определите, где вы находитесь.

2. Сделайте небольшой шаг в сторону цели.

3. Скорректируйте своё понимание на основе полученного опыта.

4. Вернитесь к первому шагу.

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

Как отметил Тим Оттингер (эксперт в области Agile), проблема начинается с простого осознания: почти все политики и процессы разработки программного обеспечения существуют для того, чтобы не допустить его выпуска.

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

В 1990-х идея выпускать ценный продукт каждые две недели была революционной. Scrum предлагал самый короткий цикл инспекции и адаптации.

Сегодня непрерывная доставка (continuous delivery) позволяет выпускать полезные обновления программного обеспечения несколько раз в день.

Это делает Scrum устаревшим.

Гибкость как подход к работе по-прежнему важна. Если серьёзно относиться к ценностям и принципам Agile-манифеста, именно этот путь и приведёт к настоящей адаптивности. Scrum мог бы стать мощным инструментом для достижения этой цели, но, к сожалению, превратился в ещё один инструмент контроля и давления.

Решение всех этих проблем существует — и оно всё ещё отображено в Scrum Guide, что особенно иронично. Но есть ли шанс спасти Scrum от «Agile-индустриального комплекса»?

Возможно, пришло время исследовать гибкость вне рамок Scrum.

Непрерывная поставка (continuous delivery) основана на том самом принципе Agile-манифеста, который был процитирован ранее: ранний и постоянный выпуск ценного программного обеспечения. В 2001 году это казалось невозможным, но сегодня этот подход позволяет делать ещё меньшие шаги — настолько маленькие, что алгоритм Дэйва Томаса можно выполнять несколько раз в день.

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

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

Недостаточно просто собрать такую команду. Её работа должна строиться на принципах моб-программирования (mob programming) — когда вся команда работает над одной задачей совместно, в одном потоке. Этот подход идеально дополняет идею непрерывной доставки.

Agile-манифест предписывает только одну конкретную практику. Это его финальный принцип:

«С определённой периодичностью команда анализирует, как стать эффективнее, и корректирует своё поведение в соответствии с этим».

Чтобы стать гибкими, не нужен никакой фреймворк.

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

---

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

• 5 марта. «Инженеры тоже плачут: как победить хаос в процессах».
  Научимся настраивать взаимодействие инженерных и проектных процессов, выбирать инженерные практики для своих проектов. Записаться

• 6 марта. «Встречи в радость, а не в тягость: фасилитация для DevRel».
  Получите набор источников для самостоятельного обучения фасилитации и сможете разобрать свои сложные кейсы фасилитации с преподавателем. Записаться

• 13 марта. «Soft Skills: Навык умения договариваться для руководителя».
  Обсудим принципы эффективного ведения переговоров и управления конфликтами; как использовать эмоциональный интеллект для достижения лучших результатов в переговорах. Записаться