Почему Agile невозможно внедрить приказом
Есть управленческий парадокс.
Руководство компании может принять решение о переходе на Agile за один день.
Можно назначить ответственных. Создать трансформационный офис. Обучить сотрудников. Сформировать команды. Ввести спринты. Назначить Scrum-мастеров и Product Owner. Перенести задачи на доски. Запустить ежедневные встречи.
Через несколько месяцев внешне организация действительно начинает выглядеть более Agile.
Но решения по-прежнему принимаются неделями.
Команды ждут согласований.
Руководители вмешиваются в работу.
Приоритеты спускаются сверху.
Сотрудники боятся экспериментировать.
Любое отклонение от первоначального плана требует объяснений.
Ошибки воспринимаются как проблема.
А ответственность за результат остаётся где-то наверху управленческой иерархии.
Компания внедрила инструменты Agile.
Но не стала гибкой.
Именно здесь находится одна из главных ошибок корпоративных трансформаций: организация пытается внедрить новый способ управления, не изменив архитектуру управления.
Приказ способен изменить процесс, но не систему отношений
Управленческий приказ — очень эффективный инструмент.
С его помощью можно установить новую процедуру.
Например:
с понедельника использовать новую информационную систему;
с первого числа сдавать отчёт в новом формате;
проводить совещание каждую среду;
использовать определённый шаблон проекта;
работать по утверждённому регламенту.
Для таких изменений административный механизм подходит прекрасно.
Но Agile затрагивает значительно более глубокий уровень.
Он меняет не только то, что делают сотрудники, но и то, как внутри организации распределяются решения, ответственность и информация.
Agile Manifesto изначально строится вокруг приоритета людей и взаимодействия над процессами и инструментами, работающего результата над избыточной документацией, сотрудничества с заказчиком над формальным контрактом и готовности реагировать на изменения над следованием первоначальному плану.
Это принципиально не набор церемоний.
Это другая логика организации работы.
И именно поэтому здесь возникает конфликт.
Компания пытается административным инструментом внедрить модель, которая требует изменения самой административной системы.
Самая простая часть Agile — поставить доску
Формальные элементы Agile внедряются удивительно быстро.
Можно провести обучение.
Разбить большой проект на короткие циклы.
Создать backlog.
Назначить Product Owner.
Начать проводить Daily.
Раз в две недели устраивать ретроспективу.
Использовать Kanban-доску.
Организационно это сравнительно несложно.
Сложности начинаются немного позже.
Команда говорит:
— Мы считаем, что эту функцию сейчас делать не нужно.
Руководитель отвечает:
— Она была утверждена в годовом плане. Делайте.
Команда говорит:
— После тестирования мы поняли, что первоначальная гипотеза была ошибочной.
В ответ слышит:
— Почему вы сразу нормально не спланировали?
Product Owner меняет приоритеты.
Но директор направления сообщает:
— Этот проект находится на контроле руководства, его нельзя переносить.
Команда хочет провести эксперимент.
Финансы требуют заранее обосновать его экономический эффект.
Получается довольно странная конструкция.
Внутри команды действует одна модель управления.
Вокруг неё — совершенно другая.
Команда работает спринтами.
Организация — годовыми планами.
Команда должна быстро менять решения.
Согласования занимают три недели.
Команда должна экспериментировать.
Ошибка ухудшает оценку сотрудника.
Команда должна быть самостоятельной.
Но существенные решения всё равно принимает руководитель.
Возникает Agile-театр.
Форма присутствует.
Механика не изменилась.
Гибкость начинается с права принимать решения
Если посмотреть на Agile не как на методологию, а как на управленческую систему, довольно быстро становится понятно: центральный вопрос находится не в спринтах.
Он находится во власти.
Кто имеет право изменить приоритет?
Кто определяет, что именно нужно сделать?
Кто может отказаться от задачи?
Кто принимает решение о выпуске продукта?
Кто может провести эксперимент?
Какой объём ресурсов команда контролирует самостоятельно?
Какие решения требуют согласования?
Именно здесь определяется реальная степень автономности.
Можно десять раз назвать команду самоорганизующейся.
Но если практически каждое существенное решение требует разрешения функционального руководителя, самоорганизации не существует.
Есть обычная иерархическая система, внутри которой сотрудники проводят Agile-церемонии.
Это одна из причин, почему формальное внедрение Agile часто почти не влияет на скорость организации.
Компания изменила процесс выполнения работы, но оставила прежним процесс принятия решений.
А ограничением системы был именно он.
Нельзя передать ответственность, не передав полномочия
Руководители иногда хотят получить от Agile очень привлекательную комбинацию.
Чтобы команды самостоятельно отвечали за результат.
Но ключевые решения при этом продолжало принимать руководство.
Так не работает.
Ответственность и полномочия должны находиться достаточно близко друг к другу.
Если команда отвечает за результат, но не может изменить приоритет, выбрать решение, перераспределить часть ресурсов или отказаться от неэффективного действия, её ответственность становится декоративной.
Возникает классическая ситуация:
результат плохой — отвечает команда;
решения, которые к нему привели, — принимала система.
В таких условиях сотрудники довольно быстро адаптируются.
Они перестают брать настоящую ответственность.
Начинают согласовывать.
Фиксировать договорённости.
Просить подтверждения.
Страховаться.
Эскалировать.
То есть ведут себя абсолютно рационально внутри существующей системы.
Потом руководство говорит:
«У нас сотрудники недостаточно инициативные».
Но инициативность здесь не является проблемой характера.
Она является следствием архитектуры ответственности.
Организация всегда сильнее методологии
Это один из важнейших принципов любых трансформаций.
Можно принести в компанию Scrum, Kanban, OKR, проектное управление, продуктовый подход или любую другую управленческую концепцию.
Но существующая организация начинает адаптировать новый инструмент под себя.
Не наоборот.
Например, появляется Product Owner.
Формально он отвечает за продукт.
Но над ним существует директор, который фактически определяет приоритеты.
Очень быстро Product Owner превращается в администратора backlog.
Появляется Scrum-мастер.
Он должен помогать команде устранять системные препятствия.
Но изменить процессы соседних подразделений он не может.
В результате начинает следить за проведением Daily и ретроспектив.
Появляется автономная команда.
Но специалисты внутри неё по-прежнему подчиняются функциональным руководителям, которые распределяют их загрузку.
Автономность становится условной.
Организация постепенно переваривает Agile.
Оставляет безопасные элементы.
И отбрасывает те, которые действительно меняют распределение власти.
Главный конфликт происходит не на уровне сотрудников
Когда Agile-трансформация буксует, иногда говорят:
«Люди сопротивляются изменениям».
Это слишком простое объяснение.
Гораздо интереснее посмотреть, кому именно изменение существующей системы создаёт реальные потери.
Представим руководителя, который много лет отвечал за подразделение.
Он определял приоритеты.
Распределял задачи.
Контролировал решения.
Согласовывал результат.
Через эту систему проходила значительная часть информации.
Теперь ему говорят:
«Мы создаём автономные продуктовые команды».
Что это означает практически?
Часть решений больше не должна проходить через него.
Команды получают больше самостоятельности.
Информация становится прозрачнее.
Экспертиза распределяется.
Роль руководителя меняется.
Формально он может полностью поддерживать Agile.
Но система власти вокруг него начинает перестраиваться.
Именно поэтому трансформации нельзя объяснять только обучением сотрудников новым практикам.
Agile затрагивает организационные роли, границы полномочий и привычную конструкцию контроля.
А такие изменения почти всегда вызывают структурное сопротивление.
KPI могут уничтожить Agile быстрее любого руководителя
Представим кросс-функциональную команду.
В ней работают специалисты из маркетинга, ИТ, продаж и операций.
Им говорят:
«Теперь вы единая команда и отвечаете за общий результат».
Звучит правильно.
Но затем начинается реальная жизнь.
У маркетинга свой KPI.
У ИТ свой.
У продаж свой.
У операций свой.
Руководители функций оценивают сотрудников по функциональным показателям.
Бюджеты тоже распределены функционально.
Карьерные решения принимаются внутри вертикалей.
Что будет делать сотрудник при конфликте интересов?
То, что влияет на его KPI, премию и карьеру.
Не потому, что он не понимает Agile.
А потому, что система стимулирует именно такое поведение.
Нельзя построить кросс-функциональное взаимодействие поверх архитектуры, которая вознаграждает локальную оптимизацию.
Люди почти всегда адаптируются не к презентациям о корпоративной культуре, а к реальным правилам распределения ресурсов, оценки и вознаграждения.
Самоорганизация не означает отсутствие управления
Здесь возникает другая крайность.
Если приказами Agile внедрить нельзя, значит, руководству нужно просто отойти в сторону и дать командам свободу.
Это тоже ошибка.
Самоорганизация без границ довольно быстро превращается в хаос.
Команда должна понимать:
какого результата от неё ждут;
какие ограничения существуют;
какие ресурсы доступны;
какие решения она принимает самостоятельно;
какие решения требуют согласования;
как её работа связана с другими командами;
по каким критериям определяется успех.
Роль руководителя при этом не исчезает.
Она становится сложнее.
Вместо постоянного распределения задач появляется проектирование среды, внутри которой команда способна принимать качественные решения самостоятельно.
Руководитель меньше управляет каждым действием.
Но значительно больше управляет контекстом.
Целями.
Ограничениями.
Приоритетами.
Архитектурой взаимодействия.
Ресурсами.
Зависимостями.
И качеством обратной связи.
Поэтому зрелая гибкая организация — это не организация с меньшим количеством управления.
Это организация с другим управлением.
Agile требует изменить отношение к плану
Традиционная управленческая система часто строится вокруг идеи предсказуемости.
Сначала мы должны определить результат.
Затем составить подробный план.
После этого выполнить его.
Отклонение означает проблему исполнения.
Для многих задач такая логика действительно работает.
Но Agile особенно полезен там, где значительная часть решения заранее неизвестна.
Мы можем понимать проблему, но не знать лучшего решения.
Можем иметь гипотезу, но не знать реакцию клиента.
Можем прогнозировать результат, но не иметь полной информации.
Тогда короткий цикл нужен не для того, чтобы сотрудники быстрее выполняли заранее определённый план.
Он нужен для того, чтобы организация быстрее получала новую информацию и корректировала действия.
Это принципиальное отличие.
Если после каждого изменения команда должна объяснять, почему она «отклонилась от плана», очень скоро она перестанет менять план.
И Agile потеряет смысл.
Нельзя приказать людям перестать бояться ошибки
Есть ещё один слой.
Эксперимент предполагает возможность отрицательного результата.
Гипотеза может не подтвердиться.
Решение может оказаться слабым.
Функция может оказаться ненужной клиенту.
Если каждый такой случай внутри компании рассматривается как управленческая ошибка, сотрудники быстро понимают правила игры.
Нужно выбирать безопасные решения.
Не брать лишнюю ответственность.
Не экспериментировать там, где результат трудно предсказать.
Согласовывать спорные действия.
И желательно иметь документ, подтверждающий, что решение принимал кто-то выше.
После этого организация может сколько угодно говорить про инновации.
Поведение людей будет определяться не словами.
Оно будет определяться последствиями ошибки.
Психологическую безопасность невозможно установить распоряжением.
Она формируется через повторяющийся опыт: что происходит с человеком, когда он сообщает плохую новость, спорит с руководителем, признаёт ошибочную гипотезу или предлагает отказаться от проекта, который поддерживает топ-менеджер.
Именно реальные реакции системы формируют культуру.
Поэтому Agile-трансформация начинается сверху, но не с приказа
Это не означает, что руководство не должно инициировать Agile.
Наоборот.
Без поддержки руководства серьёзная трансформация практически невозможна.
Но задача топ-менеджмента заключается не в том, чтобы приказать подразделениям стать гибкими.
Задача — изменить условия, внутри которых гибкость становится возможной.
Если компании нужна большая самостоятельность команд, необходимо пересмотреть полномочия.
Если требуется быстрее принимать решения — сократить цепочки согласований.
Если нужны кросс-функциональные команды — разобраться с функциональными KPI и ресурсами.
Если нужны эксперименты — изменить отношение к ошибкам.
Если требуется способность быстро менять приоритеты — изменить систему планирования и управления портфелем.
Если команда должна отвечать за результат — дать ей необходимые ресурсы и право принимать соответствующие решения.
И только после этого Scrum, Kanban и другие практики начинают усиливать систему.
Без этого они просто накладываются поверх старой архитектуры.
Настоящая трансформация становится заметна не по количеству Daily
Очень легко измерить формальную сторону Agile.
Сколько сотрудников прошли обучение.
Сколько создано команд.
Сколько Scrum-мастеров сертифицировано.
Сколько проектов переведено на доски.
Сколько проводится ретроспектив.
Но ни один из этих показателей сам по себе не говорит о гибкости организации.
Гораздо интереснее другие вопросы.
Сколько времени проходит между появлением информации и принятием решения?
Как быстро команда может изменить неработающий подход?
Сколько согласований требуется для запуска эксперимента?
Может ли сотрудник безопасно сообщить, что первоначальный план ошибочен?
Способна ли организация остановить инициативу, которая перестала создавать ценность?
Насколько близко к проблеме принимается решение?
Как быстро обратная связь превращается в изменение продукта или процесса?
Вот здесь уже начинается реальная гибкость.
Agile невозможно внедрить приказом, потому что приказ — часть системы, которую приходится менять
Можно приказать проводить Daily.
Нельзя приказать людям начать доверять друг другу.
Можно назначить Product Owner.
Нельзя одним распоряжением передать ему реальное влияние на продукт.
Можно создать кросс-функциональную команду.
Нельзя сделать её автономной, если ресурсы и решения остаются внутри функциональных вертикалей.
Можно объявить культуру экспериментов.
Нельзя получить её, продолжая наказывать за неудачные гипотезы.
Можно написать в стратегии слово Agile.
Нельзя стать гибкой организацией, сохраняя систему управления, построенную исключительно вокруг контроля, согласований и исполнения заранее утверждённого плана.
Поэтому зрелая Agile-трансформация начинается не с вопроса:
«Как внедрить Scrum во всех подразделениях?»
Она начинается с гораздо более неудобного вопроса:
«Что в нашей системе управления мешает людям быстро принимать качественные решения и адаптироваться к изменениям?»
И иногда ответ оказывается неприятным.
Проблема находится не в командах.
Не в отсутствии обучения.
Не в неправильных встречах.
И даже не в недостаточном понимании Agile.
Проблема может находиться в самой архитектуре организации — в распределении власти, ответственности, ресурсов, KPI и права принимать решения.
Именно поэтому Agile невозможно внедрить приказом.
Потому что настоящая гибкость появляется не тогда, когда сотрудники начинают работать по новой методологии.
Она появляется тогда, когда сама система управления перестаёт мешать им адаптироваться.
