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

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

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

Затем следует убедиться, что в данной среде будет применим Agile.

Для этого целесообразно обратиться к модели Кеневина (Фреймворк Cynefin), созданной в 1999 году Дейвом Сноуденом во время его работы в IBM Global Services.

Модель предлагает 4 области для принятия решений:

• простая,

• сложная,

• запутанная,

• хаос.

Из этой модели видно, что Agile более применим в запутанной среде, где нужны эксперименты и нет возможности следовать готовым практикам.

Итак, давайте посмотрим, в каких случаях Agile может быть применим:

• требуется быстрая адаптация к изменяющимся условиям;

• высокий уровень неопределенности, необходимость быстрого получения обратной связи; 

• необходимость разработки новых продуктов и проектов, оперативная реакция на изменения рынка;

• когда есть возможность работать в команде и нести общую ответственность за результат, а также тесно взаимодействовать с заказчиком и пользователями продукта или сервиса;

• когда есть поддержка высшего руководства.

В каких организациях Agile не применим?

• строго регламентированных законом. Например, военная промышленность, медицина, фармацевтика и др.;

• в областях, где гибкие подходы будут излишними (простая и сложная по Кеневину);

• где нет поддержки и согласия высшего руководства;

• где организационная культура противоречит Agile;

• где отсутствует доверие;

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

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

Давайте разберём несколько принципов, которые могут быть использованы в компаниях:

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

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

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

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

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

В Agile нет неработающих принципов, есть неподготовленные люди.

Но, чтобы принципы работали, необходимо «быть Agile». Применять Agile-инструменты недостаточно, нужно поменять мышление людей внутри компании.

Одина из основных и серьёзных проблем, с которыми многие компании и команды сталкиваются, — это отсутствие доверия.

Если доверия к сотрудникам нет, нарушаются следующие принципы:

• Над проектом должны работать мотивированные профессионалы. Чтобы
  работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

• Команда должна систематически анализировать возможные способы
  улучшения эффективности и соответственно корректировать
  стиль своей работы.

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

Это провоцирует развитие других проблем, таких как:

• несамостоятельность и пассивность сотрудников;

• замалчивание рисков и ошибок;

• конфликты, которые препятствуют продуктивности.

Также на становление Agile-мышления компании влияет оргструктура и культура компании.

Если культура компании противоречит Agile, нарушаются следующие принципы:

• На протяжении всего проекта разработчики и представители бизнеса должны
  ежедневно работать вместе.

• Непосредственное общение является наиболее практичным и эффективным
  способом обмена информацией как с самой командой, так и внутри команды.

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

Такой подход может приводить к следующим негативным последствиям:

• замедлению скорости передачи информации и принятия решений;

• замалчиванию ошибок и рисков;

• отсутствию понимания и принятия общих целей компании;

• непониманию, кто какую функцию выполняет и какой вклад вносит в проект или продукт.

Agile — это дорого!

Не менее важный фактор, препятствующий применению некоторых Agile-практик, — отсутствие возможностей финансирования непрерывного процесса разработки.

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

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

Из этого следует вывод, что Agile — это дорого. Убедитесь, что компания готова выделять ресурсы (не только деньги, но и время на обучение и адаптацию) на трансформацию.

Читайте предложения полностью.

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

Они читали Agile-манифест поверхностно, не вдумываясь в суть и забывая важный пункт:

«То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева».

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

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

Ещё одна распространённая ошибка — это дословное следование постулату «Готовность к изменениям важнее следования первоначальному плану».

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

Такая ошибка влечет следующие проблемы:

• команда демотивирована и не чувствует удовлетворения от сделанной работы;

• постоянные изменения требований в середине или конце итераций влекут трату времени и ресурсов на ненужную разработку;

• сроки всё равно будут ползти, а результат останется недостижимым.

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

И тут появляется новое убеждение, которое мешает компании стать Agile. Это слепое следование постулату «Сотрудничество с заказчиком важнее согласования условий контракта».

Я достаточно часто слышала от коллег возмущения вроде: «Ну мы же Agile! Зачем нам все эти излишние договорённости и контракты?».

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

Также я часто замечала, когда постулат «Люди и взаимодействие важнее процессов и инструментов» истолковывали как «Ну мы же Agile! Зачем нам эти ретроспективы? Мы же за прямое взаимодействие. В курилке всё обсудим».

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

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

А чтобы применять Agile, нужно мыслить Agile.

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