Перевод оригинальной статьи "Why Isn't Your Current Approach to Scaling Agile Working?" в журнале InfoQ.

У вас проблемы с масштабированием гибких подходов (Scrum, Kanban)? — Вы не одни. Даже организации, добившиеся успеха в применении гибких подходов в отдельных подразделениях, сталкиваются с проблемами в процессе масштабирования этого подхода на другие подразделения. Сложности обычно похожи друг на друга. Возможно, вам что-то знакомо из перечисленного?

1. Копирование модели другой организации.
   
2. Оргструктура противоречит целям гибкости.
   
3. Использование "copy paste" подхода для масштабирования.
   
4. Оптимизация разных частей организации по отдельности.
   
5. Недостаточные инвестиции в инженерные практики.

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

Масштабное внедрение Аджайл-подходов требует изменения организационной структуры, политик работы и поведения людей. Это сложная задача, как и вообще любые крупномасштабные изменения.

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

Почему? — Потому что в Аджайл-мире не бывает коротких путей. Вы должны самостоятельно определить, что такое гибкость для вас и как сделать гибкой вашу работу. Нельзя скопировать ответы другой организации, потому что их вопросы (т.е. проблемы) отличаются от ваших.

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

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

Например, в 2001 году Тойота хотела опубликовать книгу под названием «The Toyota Way» (в русском переводе «Дао Toyota»). Однако руководство компании выступило против такого названия, предложив взамен «The Toyota Way 2001», потому что в следующем году их способы работы должны были измениться.

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

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

Организационная структура, способствующая гибкости, дает следующие преимущества:

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

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

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

Проиллюстрируем это на примере дизайна гоночных машин для Формулы-1 и для гонок по пересеченной местности.

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

А команда, участвующая в гонках по пересеченной местности, например, ралли-марафон Дакар, должна везти все запасные детали с собой. Чтобы достичь финиша быстрее соперников, они должны справляться с различными условиями маршрута и уметь импровизировать.

И в Формуле-1, и в гонках по пересеченной местности цель дизайна машин — достижение максимальной скорости, но в случае гонки по пересеченной местности степень неизвестности означает, что и машина, и команда должны уметь быстро адаптироваться. Машины Формулы-1 быстрее, но только потому, что ездят в контролируемой среде, в ралли они бы сразу же непоправимо сломались.

Сегодня жизнь организаций больше похожа на гонку по пересеченной местности, чем на Формулу-1, и победитель определяется способностью адаптироваться к изменяющимся условиям.

Типичная оргструктура — Иерархия

Как упоминалось выше, Иерархия оптимизирована под эффективное выполнение плана, а отклонения от плана быстро выявляются и наказываются.

Джон Коттер подчеркивает и другие важные цели Иерархии:

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

Гибкость по своей сути предполагает возникновение условий, при которых план окажется ошибочным, и придется его пересмотреть или отказаться от него. Для иерархической организации это представляет угрозу. Но нельзя одновременно ориентироваться на контроль и эффективность — и на адаптивность и скорость обучения. Поэтому при поверхностных изменениях оргструктуры старая системная цель по-прежнему преобладает.

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

Еще одно ошибочное представление заключается в том, что масштабирование Аджайл-подходов означает, что меняться должны только команды, а система менеджмента, оргструктура, политики и культура организации в целом, могут оставаться прежними.
Организации, которые придерживаются этого мнения, масштабируют Аджайл путем механического копирования Скрам-команд. Каждая новая Скрам-команда добавляет своего Владельца Продукта и свой Бэклог, Команду разработки и часто еще и Скрам-мастера.

Такая стратегия начинает быстро разваливаться, когда нескольким Скрам-командам приходится работать над одним продуктом. По мере добавления новых Скрам-команд им приходится координировать деятельность, и поэтому они добавляют новые процессы и новые координирующие роли, чтобы управлять взаимозависимостями. Каждая новая команда стремится оптимизировать свои результаты, но не рассматривает продукт целиком.

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

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

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

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

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

Это означает следующее:

• Оргструктура построена вокруг продуктов, чтобы поставлять клиентам наилучшие результаты без задержек.
  
  
• Организация состоит из фиче-команд, которые работают над единым продуктом.
  
  
• Переход к кросс-функциональным командам, которые отчитываются перед кросс-функциональными руководителями.
  
  
• Внедрение финансовой модели, при которой Владелец Продукта имеет полномочия принимать инвестиционные решения на основании фидбека от клиентов и пользователей и рынка в целом.
  
  
• Изменение системы управления и культуры, ведущее к пониманию ценности обучения и совместной работы кросс-функциональных команд; постоянное расширение возможностей как команд, так и их членов, чтобы они могли самостоятельно решать проблемы; команды получают поддержку для расширения своих возможностей.
  

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

В разработке программного обеспечения по принципам Аджайла ключевой момент заключается в том, что ваши программы должны быть достаточно гибкими, чтобы их можно было быстро изменить с небольшими затратами и проверять, соответствует ли результат ожиданиям. Для этого нужно разрабатывать высококачественное ПО с помощью гибких инженерных практик. Вы можете внедрить какие угодно процессы, стикеры, Скрам-мастеров и оргструктуру, соответствующую Аджайлу, но без высококачественного ПО и профессионализма в инженерных практиках вы не получите результата.

Масштабирование требует в первую очередь эффективной автоматизации сборки и тестирования, а также полной автоматизации всего процесса поставки ПО. Для масштабирования также нужно, чтобы разрабатываемый продукт имел модульную архитектуру, чтобы любую его часть можно было легко изменить или заменить. Также важную роль играет управление версиями ПО. Чтобы эффективно координировать работу команд, а также чтобы предотвратить скрытый рост технического долга, необходим подход trunk-based development («стволовая разработка») — и это только начало.

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

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

LeSS рассматривает имеющуюся оргструктуру как главное препятствие для разработки продукта несколькими командами, поэтому в первую очередь решает эту проблему.

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

В таблице отражены эти отличия и показано, как упомянутые подходы позволяют справиться с пятью основными сложностями:

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

В ходе работы необходимо искать возможности для внесения некоторых изменений:

• Изменения в оргструктуре. Могут понадобиться новые рабочие соглашения, политики и новая оргструктура, чтобы акцент сместился с утилизации ресурсов на максимизацию ценности для клиентов. Ценность создается в организации горизонтально, в подразделениях, а не вертикально по традиционной оргструктуре.
  
  
• Изменения в компетенциях. Сотрудникам может понадобиться изучить новые практики, чтобы с требуемой частотой поставлять высококачественный продукт, созданный совместно с пользователями.
  
  
• Изменения в поведении. Сотрудников попросят работать в составе реальных фиче-команд команд и взаимодействовать с ними. При этом команды будут владеть результатами.

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