Данный материал — перевод статьи за авторством Matthew Heusser, Managing Consultant в Excelon Developmen. Редактура — Ирина Махмутова.

Почему руководство не принимает agile и что вы можете с этим сделать

Первый в моей практике переход в agile имел полную поддержку высшего руководства компании. Топ менеджмент обеспечил финансирование всех необходимых тренингов, инструментов и консалтинга.
Руководители провели встречи со всеми сотрудниками компании, на которых разъяснили новый подход к работе и то, как изменятся документирование, разработка и структура команд. Правда была одна странная штука: проектные планы, управление портфелем и бюджетирование должны были остаться прежними, не говоря уже про HR и финансы. С тех пор я слышал эту историю много раз, разница была только в деталях — что именно должно было остаться неизменным. При этом все (за исключением может быть пары executives)) согласно кивали.
Наши топы часто тратят уйму времени и денег на agile, но при этом дискредитируют инициативы, которые продвигают. Это не просто частая проблема; это практически всеобщая проблема, а всеобщие проблемы склонны иметь системные причины.
Я приведу пять самых распространенных причин, почему топы не получают agile — и что с этим делать.

Enterprise Agile: Поторопитесь ускориться быстрее

1. Руководство рассматривает agile как активности исключительно командного уровня

Рассмотрим ситуацию: Обычная agile «трансформация» начинается с организации персонала в Scrum команды. Это сокращает время передачи требований в разработку, кода из разработки в тестирование, но никак не решает вопросов внешних зависимостей команды от ИТ, эксплуатации или HR.
Как недавно отметил Mike Cottmeyer pointed out на конференции Agile & Beyond — внешние зависимости разрушают устойчивую производительность команды (velocity).
А когда производительность команды неустойчива, невозможно сказать, когда проект будет завершен.
Cottmeyer отмечал, что именно в этот момент у agile-коучей начинаются проблемы при попытке уговорить руководителей «начать доверять командам». Доверие к командам это прекрасно, но у руководства возникают вопросы, на которые нет ответов. Например: «Когда мы можем открыть новый проект? На что направить маркетинговый бюджет и когда? Сколько заложить в бюджет, чтобы сделать следующую штуку?»
Cottmeyer говорит о том, что внешние зависимости команды это ключевое препятствие. Он рекомендует компаниям, которые стоят на пути адаптации или «внедрения Agile» убирать зависимости, искать обходные пути, пересматривать любые соглашения об уровне сервиса (SLA), чтобы сделать функциональные команды более предсказуемыми. Scrum и XP не предназначены для решения проблем взаимозависимости команд, а я вижу эти проблемы в любой организации с тремя и более командами.
Почти всегда настоящее узкое горло — это взаимозависимости команд. И именно с ним agile методики командного уровня не помогут, а руководители окажутся без желанных результатов и продолжат задавать неудобные вопросы.

2. Руководство не получает обучения необходимого уровня

Недавно мои коллеги проводили двухдневный тренинг для высшего руководства очень прибыльной компании. Тренинг назывался «Agile for Executives», но выяснилось, что это скорее тренинг по Scrum — речь шла о спринтах, историях и самоорганизованных командах. После тренинга у руководства появилось много идей о том, как «те ребята» должны «делать» программы, но оно не получило никаких реальных инструментов управления зависимостями или понимания, что делать с портфелем и бюджетами.
Большая часть руководства слишком занята, чтобы пойти на двухдневный тренинг. Обучение Scrum им в любом случае бесполезно. Как впрочем не сильно помогут и все книги про разработку программного обеспечения, которые обычно читают команды. Сайты о том, как требуется меняться руководству, полны многозначительных советов типа «исследуйте и адаптируйте» или «учитесь быстро», но эти советы никак не говорят руководству о том, как им в реальности управлять проектами в больших организациях.
Eric Willeke, советник по корпоративной гибкости в CA Technologies утверждает, что большинство agile-коучей уровня команды и программы никогда не принимали решения на том уровне, который является повседневным для руководства. И тот факт, что у них нет этого совершенно необходимого опыта означает, что они не готовы обеспечить обучение, которое требуется руководству.

3. Водопадная модель скрывает неэффективность от руководства

Когда водопад был обычной практикой, организации пытались вести две дюжины инициатив, когда-то меньше, когда-то больше. Примерно первые восемь были высокоприритетными, следующе восемь среднеприоритетными и оставшиеся восемь низкоприоритетными. Даты в плане появлялись на основании прошлого опыта и принятых обязательствах, а PMO создавал виртуальные команды, чтобы сделать обещанное.
Хорошая штука в таком подходе в том, что если что-то затягивается, то команда может легко переключиться и сфокусироваться на чем-то, что помечено как высокоприоритетное. Это позволяет избежать печальных последствий закона Брукса (добавление людей на последних стадиях проекта удлиняет его), потому что просто увеличивает время работы или процент участия уже задействованных участников проекта — да-да, вы не добавляете «больше» людей.
В результате некоторые компании, использующие водопад, сумели избежать части проблем от задержанных проектов.
Конечно то, что было помечено как низкоприоритетное, делается крайне долго, если вообще делается, но мы же знаем, что они и были низкоприоритетными. Организация получает то. что было заявлено как необходимое, примерно в запланированное время. И конечно, все известные типы скрытой неэффективности водопада здесь присутствуют: все происходит долго, и полно необдуманных решений, взаимозависимостей и переделок. Но для управления это не так значимо, потому что проекты завершаются.
Завершенный проект — это довольно приличный клапан сброса давления, который организация теряет, когда переходит в agile разработку и ограничивает количество задач в работе. Почему? Потому что, когда команды выделены на один проект, не остается того процента времени, который можно отжать у них, нет способа подшаманить, чтобы компенсировать потери. Таким образом у менеджмента становится на один рычаг меньше для выруливания в сторону дедлайна.
Конечно, всегда сложно держаться курса, но некоторые организации научились скрывать это с помощью водопада. Менеджеры, которые нуждаются в этом, обнаружат, что инструмент, доступный в водопаде, исчезает в agile разработке. Если организация заблокирована многочисленными взаимозависимостями команд и производительность команд нестабильна, результат будет по-прежнему запаздывать.
Для руководства в таких компаниях все выглядит так, как будто все стало только хуже, когда они перешли на agile.

4. Ведущие руководители слишком сосредоточены на каком-то одном аспекте

DevOps невероятно привлекательная и популярная по многим причинам штука. Высшее руководство реально хочет DevOps, но некоторые верят, что DevOps можно купить и «установить». Если вы обзавелись современным средством контроля версий и добавили немного непрерывной интеграции, автоматизированного тестирования и выкладку одной кнопкой, вы волшебным образом сократили путь от запроса до реализации с месяцев до минут.
Все это может быть правдой, есть реально мощные инструменты, но организация получает значительно больше, воспитывая в себе эффективность, а не приобретая инструменты. Когда ScotiaBank проводил agile эксперимент, они обнаружили семь уровней согласования для внесения изменения в продуктивную среду. Консалтинговая компания, которая запускала процесс, просто наняла больше людей, которые занимались согласованиями параллельно разработке. Это давало свои плоды, а еще пополняло счета консалтинговой компании. Dave Dame и Aaron Sampson, которые работали на этом проекте, придерживались другой тактики: изменить процесс так, чтобы контроль соответствовал рискам (теперь уже сниженным).
В то же время вы не сможете снижать риски, если единственная вещь, которая интересует руководство, — это статус запуска непрерывной поставки, и единственное препятствие, которое они видят, это «Doker-изация серверной фермы».
Полная agile-трансформация будет включать изменения организационной структуры, процессов развития и построения технических компетенций, культуры, управления продуктами, закупок, практик контрактованная и, да, даже HR. Фокусировка на одной из этих областей или даже на нескольких из них может привести к созданию чего-то типа трубопровода с кучей засоров, колен и букетом других проблем.

5. Множество конфликтующих целей на уровне руководителей

Agile подход применяется не ради самого себя, а для получения желаемого результата. CA Technologies’ Willeke спешит отметить, что «гибкость без цели лишена смысла». Внедрение agile, по его мнению, должно быть неразрывно связано с бизнес результатом — сокращением time to market, снижением издержек, лучшим клиентским сервисом, лучшим соответствием продукта потребностям заказчика и более высоким качеством. Но если цели или «зачем» недостаточно ясны, то «что» и «как» будут перепутаны. Это самое «что» может в конце концов оказаться совсем не тем, что руководство думало себе получить.
Выделить единственную цель для движения в agile может быть крайне сложно и, на самом деле, не нужно: в конце концов, руководству были обещаны все указанные выше преимущества (смотри пункт 1). Но всякое может быть.

Как это починить

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

https://habrahabr.ru/post/333032/