В типичной Agile-трансформации мы встречаем много сопротивления, и это нормально. Большие организации — это социальные системы, на которых действует правило гомеостаза: они стремятся к статусу-кво и не хотят меняться.
Законы Лармана как раз об этом:
- Организации оптимизированы для сохранения статус-кво — особенно власти и структур среднего звена.
- Поэтому любые изменения сводятся к переименованию старого в новое.
- Поэтому изменения высмеиваются как «пуризм», «религия» или «непрактичность» — чтобы отвлечь внимание и сохранить статус-кво.
- Поэтому тех, кто теряет позиции, переводят в «коучи по изменениям», создавая видимость трансформации и вводя в заблуждение руководство.
- В крупных организациях культура следует за структурой. Чтобы изменить культуру, нужно менять систему: роли, иерархии, карьерные пути, метрики и награды.
Как сказал Джон Седдон:
«Попытки изменить культуру организации — это глупость, они всегда терпят неудачу. Поведение людей (культура) — продукт системы; когда вы меняете систему, поведение людей меняется».
Когда я иду в трансформацию, то стараюсь придерживаться трех принципов:
- Глубоко и узко
- Поддержка снизу и сверху
- Используем волонтерство
Глубоко и узко
Самый важный принцип, который напрямую вытекает из законов Лармана. Культура следует за структурой, поэтому мы хотим провести очень глубокие изменения в ограниченной части организации (50–70 человек), меняя весь организационный дизайн: структуру власти, процессы, систему наград и HR-политики.
Фактически это создание параллельной организации с другими правилами. Мы формируем небольшую продуктовую группу, которая должна показать кратный скачок в адаптивности и скорости — совсем другие результаты по сравнению с остальной компанией. Поэтому изменения должны быть глубокими: наивно ожидать роста в 2–6 раз, ограничиваясь поверхностными мерами.
Вторая причина — управляемость рисков. Мы ограничиваем скоуп, чтобы учиться на небольшом участке организации, а затем, получив ценные знания, масштабировать изменения дальше. Такой подход не ставит под угрозу бизнес всей компании, а запускает лишь пилот.
Поддержка снизу и сверху
Этот принцип логично вытекает из первого. Чтобы изменения состоялись, особенно глубокие и узкие, нужна поддержка и сверху, и снизу.
- Сверху — от топ-менеджмента, потому что только они могут менять организационный дизайн: структуру, процессы, систему наград и HR-политику. Именно у них ключи от изменений.
- Снизу — от сотрудников, потому что заставлять взрослых людей меняться бессмысленно. Если трансформация спускается директивно, без добровольного участия, это почти гарантирует сопротивление и низкое вовлечение.
Я был свидетелем случаев, когда команды заставляли «идти в Agile». Результат — морально и физически изнуряющая «кровавая баня», в которой люди выгорают и массово уходят.
Используем волонтерство
Принцип волонтерства помогает обеспечить поддержку и сверху, и снизу.
Я применяю его дважды.
Первый раз — при выборе продукта или продуктовой группы для пилота. Чаще всего топ-менеджмент уже имеет идеи, где запустить трансформацию (исходя из стратегии и бизнеса). Но я предлагаю смотреть шире и рассматривать всю организацию. Владельцам продуктов я предлагаю «поднять руку», если они готовы на глубокие и узкие изменения. Это фиксируется в Контракте для волонтёров, о котором расскажу ниже.
Второй раз — внутри пилотной группы (50–70 человек). Естественно, часть сотрудников поддерживает изменения, а часть — нет. Поэтому мы снова включаем принцип волонтерства: те, кто не хочет участвовать, могут перейти в другие подразделения, а те, кто наоборот заинтересован, могут присоединиться к пилоту из других частей организации.
Контракт для волонтёров
Сразу оговорюсь: мне как Agile-коучу неинтересно заниматься увеличением скорости на 10–30%. Это смешные и неамбициозные цифры. Если компания правильно применяет принципы бережливого мышления, то прирост должен быть кратным — в 2–6 раз. В противном случае делается что-то не то.
Поэтому я в пилотах всегда предлагаю идти на максимум и ставить амбициозные цели. Мой контракт для волонтёров выглядит жестко: я выкручиваю «настройки» организационного дизайна до упора. В основе — звезда Гэлбрейта:
Контракт для волонтеров в формате звезды Гилбрейта
Структура.
Полуавтономная продуктовая группа из 3–5 взаимозаменяемых фиче-команд. Минимальный набор ролей: Product Owner, Scrum Master / Agile-коуч и команды. Все остальные «погоны» — архитектор, тестировщик, бизнес-аналитик, тимлид и другие — убираются. Почему? Потому что каждая новая роль отбирает у команд часть ответственности и мешает их взрослению. Чем меньше лишних ролей, тем быстрее возникает самоуправление.
Процессы.
Фиче-команды — это фундамент, но его недостаточно. Чтобы выйти на кратные ускорения, мы должны перейти в режим Swarming / One-Piece Flow (ссылка): каждая команда работает над одной фичей одновременно. Да, кто-то будет простаивать, и это нормально. Мы оптимизируем поток, а не загрузку ресурсов. Координация между командами строится без формальных ролей: через сообщества, менторов компонентов, открытое пространство, совместное владение кодом и другие неформальные механизмы взаимодействия.
Метрики и награды.
У продуктовой группы есть единая Product Goal. Краткосрочные цели могут ставиться командами на уровне спринтов, но долгосрочные цели — только общие. Бонусы и KPI на уровне индивидуумов или отдельных команд убираются. Если полностью отказаться от них невозможно, то хотя бы делаем их общими на всю группу. Это заставляет людей не просто выполнять свою часть, а помогать друг другу и тянуться за общий результат.
HR-политики.
Когда команды берут end-to-end ответственность и работают в One-Piece Flow, неизбежно возникает ситуация: кто-то перегружен, кто-то недогружен. Чтобы это не превращалось в проблему, мы проектируем HR-политику вокруг T-shape и M-shape развития сотрудников. Оплата за навыки, зарплатные формулы, кросс-обучение — инструменты могут быть разные, суть одна: рост гибкости и взаимопомощи внутри команд. Ответственность за развитие передаем самим командам. Agile-коучи помогают с инструментами вроде «звездных карт», которые позволяют отслеживать прогресс в гибкости и зрелости.
Общие цели и общие награды требуют живого механизма peer-to-peer давления. Поэтому в контракте всегда есть пункт о регулярной неформальной обратной связи между командами: открытые обсуждения, ревью, совместные ретроспективы. Это создает здоровое напряжение и держит всех в тонусе.
Главные мысли
Мир больших организаций — это всегда мир больших сопротивлений, и это абсолютно нормально.
Чтобы повысить вероятность успеха трансформации, используйте три принципа:
- Глубоко и узко — меняйте систему целиком, но на ограниченном участке.
- Поддержка снизу и сверху — топы дают ключи от системы, люди дают энергию изменений.
- Волонтерство — запускайте трансформацию только с теми, кто готов, и закрепляйте это жестким контрактом.
Применяйте принцип волонтерства на нескольких уровнях, не бойтесь жестких правил в контракте, и именно тогда вы получите не проценты, а кратные приросты скорости и адаптивности.