Мало кто из апологетов Agile/Scrum готов признать вслух, что в большинстве IT‑компаний эта управленческая концепция существует лишь в виде ритуалов и призывов. Стендапы проводятся, ретроспективы — по расписанию, Jira (или любой аналогичный инструмент) пестрит задачами, а бизнес‑результата — ноль.

С одной стороны, по данным разных исследований, от 71% до 97% организаций используют Agile [1,2]. А Scrum среди Agile‑команд является доминирующим фреймворком — его применяют от 63% до 87% (с учётом гибридов) [3]. Но, с другой стороны, реальную бизнес‑ценность от внедрения получают лишь 33% компаний [4]. Данные о провале трансформаций от McKinsey и BCG варьируются от 70% до 88% [5].

Мы наблюдаем парадокс: инструменты есть, а результата нет. Это порождает феномены Agile Theater и Zombie Scrum, когда команды проводят ритуалы, но их способ принятия решений не меняется [4]. Возникает миф, что в IT всё хорошо с бизнес‑процессами. Вот весьма показательный комментарий участника Хабра: «В ИТ‑компании нет хаоса, а есть отлаженные рабочие процессы. Лидеры тут не нужны, а нужны хорошие администраторы». Именно эта уверенность в собственном благополучии часто становится главным препятствием для настоящих изменений.

Три фундаментальные ошибки Agile‑трансформаций

В чём суть любого изменения в организациях или командах? По моему опыту, большинство руководителей не могут дать однозначного ответа на этот вопрос. А логика между тем проста: любое изменение нужно для получения лучшего результата, а результат всегда является следствием действий. Поэтому любое изменение является изменением организационного (или командного) поведения — совокупности действий, которые должны привести к новым, лучшим результатам. Всё остальное: ценности, установки, бизнес‑процессы, навыки и знания (список можно продолжить) — это инструменты для изменения поведения.
Игнорирование или непонимание этой логики приводит к трём фундаментальным ошибкам. Они универсальны при всех организационных/командных изменениях, но связка Agile/Scrum является очень ярким и наглядным примером того, как это происходит.

1. Нет реальной боли

В большинстве организаций большая часть руководителей воспринимают те или иные концепции, в том числе Agile/Scrum, как модный тренд, а не как инструмент для решения конкретных проблем - реального прорыва в достижении амбициозных целей. Но как распознать цель, делающую концепцию рабочей, а не пустой декорацией? Джозеф Гренни предлагает простой индикатор: «Показатель эффективности любой целевой метрики — то, как она влияет на поведение» [6]. Это глубокая мысль, так как она подразумевает, что любая цель должна оцениваться не по тому, насколько красиво она выглядит на дашборде, а по её способности менять поведение людей.

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

2. Нет ясного понимания, какое поведение мы хотим изменить

Большинство руководителей, к сожалению, вообще не мыслят категориями поведения. Они мыслят категориями установок и/или бизнес‑процессов (фреймворков). В поведенческой эволюционной экономике этот феномен называется «провал при копировании рутины (поведенческой привычки) из‑за причинной неоднозначности» [7]. Он означает, что руководитель, внедряя управленческую технологию, не понимает, какая именно часть поведения в оригинале отвечала за успех. В результате он копирует всё подряд (включая второстепенные, а иногда и вредные элементы), а ключевой элемент поведения либо упускает, либо искажает.

История с Agile/Scrum — лучшая тому иллюстрация. Переход от Waterfall к Agile — это замена одних поведенческих моделей (рутин) на другие. Манифест Agile (2001) появился как смена установок для этого перехода: четыре ценности и двенадцать принципов. Никаких процессов, никаких досок. Только философия: «Люди и взаимодействие важнее процессов и инструментов», «Реагирование на изменения важнее следования плану». Это был набор установок, призванных изменить рутины (привычное поведение). Разработчики должны начать общаться напрямую, быстро реагировать, думать о ценности, а не о документации.
А потом случилось то, что случается с любой успешной идеей: её завернули во фреймворки (Scrum, SAFe, LeSS, Spotify Model), дабы повлиять на нужное поведение. У каждого — ритуалы, артефакты, роли, регламенты. Философия обросла процессами и множеством рутин.

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

3. Отсутствие системного подхода к изменению поведения

Почему новое поведение не возникает само собой, даже если мы его чётко сформулировали и артикулировали? Потому что мы не анализируем системно, что именно поддерживает старые привычки. Наиболее часто руководители совершают ошибку атрибуции: считают, что проблема только в людях («они такие»), и не учитывают другие факторы, определяющие текущее поведение сотрудников.

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

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

Практический алгоритм: как повысить отдачу от Agile/Scrum

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

Шаг 1. Сформулируйте амбициозную цель

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

Обратите внимание: цель должна быть конкретной и измеримой. «Стать лучше» — не цель. «Улучшить качество» — не цель. «Сократить количество критических инцидентов с 10 до 2 за полгода» — это может быть хорошей целью.

Как сформулировать амбициозную цель для своей команды?

• Бенчмаркинг по лучшим IT‑командам. Посмотрите, какие показатели у лидеров рынка, какие прорывы и благодаря чему были ими совершены.

• Что из этого критично для вашей команды? Не пытайтесь улучшать всё сразу. Что даст ощутимый эффект? Какой показатель, если его улучшить, изменит всю картину?

• В чём больше всего заинтересованы стейкхолдеры? Что важно для бизнеса?

• Требует ли цель изменения поведения?

Шаг 2. Сфокусироваться на ограниченном количестве жизненно важного поведения

Почему важен фокус при изменении поведения?

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

Во‑вторых, существуют стартовые привычки. Это модели поведения, которые, будучи внедрёнными, автоматически запускают каскад других улучшений. В науке о влиянии это называют жизненно важным поведением (Vital Behaviours) [7]. Оно как рычаг: вы прилагаете усилие в одной точке, а эффект распространяется на всю систему. Именно так и работает настоящая трансформация — не через широкий фронт, а через точечные изменения, которые создают системный эффект.

Пример из мира Agile

Если разработчики регулярно начинают высказывать сомнения вслух, это автоматически:

• Повышает психологическую безопасность в команде.

• Инициирует процесс обсуждения и увеличивает количество найденных рисков на ранних стадиях.

• Снижает число критических инцидентов и «разборок» в духе «кто виноват».

• Улучшает качество ревью и совместной работы.

Для эффективного отыскания и описания жизненно важного поведения полезно использовать следующую формулу: Ключевой момент (когда?) → Поведение (что именно делаем?).

Не «Мы должны быть более открытыми», а «Когда на ретроспективе или при обсуждении спринта разработчик замечает потенциальную проблему, но не уверен на 100% в своём мнении, он озвучивает свои мысли, используя формулировку, явно маркирующую его высказывание как сомнение (а не утверждение)».

Чувствуете разницу? Это конкретное, наблюдаемое действие. Вы можете увидеть, происходит оно или нет.

Исследования показывают, что в большинстве команд основным ограничением для Agile‑трансформаций является низкий уровень психологической безопасности. Люди боятся высказывать сомнения, признавать ошибки, предлагать нестандартные решения. Они предпочитают молчать, чтобы не рисковать репутацией и не провоцировать критику. Поэтому для разбора следующих шагов я взял пример одной конкретной цели и одного жизненно важного поведения, которое ярко иллюстрирует проблему психологической безопасности и трудных диалогов. Эти два элемента будут проходить через всю оставшуюся часть статьи.

Цель: Сократить количество критических инцидентов в продакшне с 10 до 2 в квартал в течение следующих 6 месяцев.

Жизненно важное поведение: Когда на ретроспективе или при обсуждении спринта разработчик замечает потенциальную проблему, но не уверен на 100% в своём мнении, он озвучивает свои мысли, используя формулировку, явно маркирующую его высказывание как сомнение (а не утверждение).

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

Шаг 3. Анализ причин, поддерживающих существующие привычки

Помните, мы выше обсуждали ошибку атрибуции? Модель «Шесть источников влияния» помогает избежать её. Она даёт системный взгляд на проблему и показывает, что именно поддерживает текущее поведение.

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

Шаг 4. Добавление факторов, обеспечивающих новое поведение

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

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

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

Пример добавления факторов влияния для достижения устойчивого поведения

Когда на ретроспективе или при обсуждении спринта разработчик замечает потенциальную проблему, но не уверен на 100% в своём мнении, он озвучивает свои мысли, используя формулировку, явно маркирующую его высказывание как сомнение (а не утверждение).

Личные источники влияния 

→ Личная способность: Развитие навыков высказывания несогласия, признания неуверенности, ведения трудных диалогов. Именно здесь лежит корень проблемы в большинстве случаев. Людей нужно учить формулировать свои сомнения экологично: «Я не уверен, но у меня есть сомнения, давайте проверим вместе» вместо «У нас проблемы». Что еще важнее — уметь продолжить диалог, если в ответ услышишь «Ты сначала разберись со своими сомнениями сам, а потом говори!»

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

→ Личная мотивация: Акцент на ценностях. Проблема не в том, что у людей другие ценности. Чаще проблема в том, что их система ценностей «спит» и её нужно разбудить.

Как это сделать:

• Приобретение опыта: «Давайте попробуем провести эксперимент в следующем спринте: каждый раз, когда у вас есть сомнения, просто скажите об этом. Мы не будем вас критиковать. Мы увидим, как это повлияет на число инцидентов».

• Сторителлинг: Рассказывайте истории о том, как признание неуверенности спасло проект. Или как молчание привело к катастрофе. Люди запоминают не абстрактные ценности, а конкретные истории.

Социальные источники влияния

→ Стратегия «жертвования» — чем я, как лидер, готов пожертвовать, чтобы продемонстрировать серьёзное отношение к новым моделям поведения?

• Время: Я готов тратить время на разбор ошибок и сомнений, а не только на статус‑митинги. Если я говорю, что высказывать сомнения важно, но при этом не даю на это времени, я посылаю противоречивый сигнал.

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

• Эго: Я готов первым признать свою неуверенность в каком‑то вопросе. «Ребята, я не до конца понимаю этот технический момент. Давайте вместе разберёмся». Это показывает, что признание неуверенности — это норма, а не потеря лица.

→ Использование неформальных лидеров. Они первыми должны начать практиковать новое поведение. Если уважаемый в команде разработчик первым скажет «Я тут не уверен, давайте вместе посмотрим», это снизит опасения для всех остальных.

Структурные источники влияния

→ Структурная способность:

• Создайте безопасные каналы для оповещения о проблемах. Например, чат для «красных флагов», где поощряется высказывать сомнения, либо специально выделенное время на спринтах, ретро и т.п.

• Введите чек‑листы для ревью, где один из пунктов — «есть ли у вас неуверенность в чём‑то?».

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

→ Структурная мотивация:

• Бонусы, поощрения, карьерный рост надо увязывать с жизненно важным поведением и использовать аккуратно — риск формального выполнения. Не поощряйте «количество найденных багов», а поощряйте «факт высказывания сомнений и совместной проверки».

• Например, отдельная номинация на ретроспективе «За смелость сказать о риске» или включение этого пункта в критерии повышения.

• Важно: не создавайте систему, где люди будут высказывать сомнения только ради бонуса. Это превратит жизненно важное поведение в формальность. Должна быть внутренняя связь между поведением и результатом.

Как выглядит успешная трансформация: системный эффект

Когда вы системно работаете со всеми шестью источниками влияния, происходит каскадный эффект:

• Разработчики учатся формулировать сомнения и противостоять негативу экологично (личная способность).

• Они видят, что их коллеги и руководитель поддерживают такое поведение (социальная мотивация и способность).

• Руководитель первым признаёт свою неуверенность и показывает, что это норма (социальный пример).

• Процессы и инструменты позволяют быстро проверить сомнения, не затягивая релиз (структурная способность).

• Бонусы и KPI поощряют не только скорость, но и качество (структурная мотивация).

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

И самое главное: поведение становится привычкой. Люди перестают думать о том, как высказать сомнение, они просто это делают. Это и есть настоящая трансформация.

Вместо заключения: системный подход вместо магии

Agile/SCRUM не работают не потому, что методология плоха. Они не работают потому, что мы забываем про амбициозные цели, про жизненно важное поведение, про системный анализ препятствий. Мы пытаемся изменить сложную систему с неправильного конца — с призывов или с алгоритмов и ритуалов вместо того, чтобы начать с нового поведения и системно поддерживать его на всех уровнях.

Начните с вопроса: «Какое поведение нашей команды приведёт к амбициозной цели?». 

Источники:

1. State of Agile Report, 2024.

2. LinkedIn пост Kiran Babu, 2025.

3. Prabol Blog: How Many Companies Use Scrum?

4. LinkedIn пост Thom Baxter, 2025.

5. Why Agile Transformations Fail: Look at Behaviors, Not Just Process.

6. Patterson, K., Grenny, J., et al. «Crucial Influence» (ранее «Influencer»), McGraw‑Hill, 2013.

7. Дози Дж., Нельсон Р. Р., Уинтер С. Г. (ред.). Природа и динамика организационных способностей. — Oxford: Oxford University Press, 2000.

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

Если вам интересна тема влияния и изменения поведения в командах, приглашаю в наш Телеграм‑канал «90-й перцентиль». По тегу #МастерВлияния вы найдёте там посты на эту тему.