Как внедрить Agile в компании, не разрушив её

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

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

Сотни компаний от небольших фирм до крупных предприятий (Spotify, Netflix) сразу работали по Agile и добились успеха. Некоторые вроде Amazon и USAA (компания финансовых услуг для военного сообщества) переходили от традиционной иерархии к гибким методам более постепенно. В то же время есть случаи, когда такая реорганизация процессов пользы не принесла.

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

Agile-команды работают в сложных условиях, когда решения проблем ещё не найдены или требования к проекту могут изменяться. Обычные операции (техническое обслуживание, закупки или финансовый учёт) не так интересны для них. Гибкие методологии изначально применялись в ИТ-сфере, а после перекочевали в маркетинг и даже в HR.

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

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

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

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

Например, компания Bosch при переходе к гибкой методологии разграничила работу agile-команд и традиционных структур, что привело к подрыву целостности компании. Изначально в компании попробовали жёстко систематизировать процессы управления, но вскоре стало ясно, что им не хватает гибкости.

Тогда члены правления поделились на группы, каждая из которых пробовала разные гибкие подходы. Так появились 10 принципов лидерства, введённых в 2016 году. Сегодня в Bosch баланс между гибкими подходами и традиционными методами — так проще и быстрее адаптироваться к изменениям на рынке.

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

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

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

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

Обычно лидеры после классификации возможностей выделяют три основных компонента.

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

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

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

В 2015 году руководство ING Netherlands, ожидая рост потребительского спроса на цифровые решения и вторжение новых конкурентов, распустило организационные структуры, выполнявшие самые инновационные функции (развитие технологий, управление производством, маркетинг).

Вместо них создали небольшие agile-отряды, и около 40% сотрудников должны были занять новые рабочие места и полностью поменять своё мышление. (Смотрите "One Bank’s Agile Team Experiment" HBR, March-April 2018).

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

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

Джефф Безос (глава и основатель Amazon) полагает, что на полную отдачу требуется 5−7 лет, но признаки улучшения можно видеть в короткие сроки: упрощение работы с клиентами, ускоренный выпуск продукции.

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

Показ конкретных достижений и успехов в работе помог поддерживать мотивацию. Через некоторое время уже 80% всей организации работало по Agile. Люди в сфере продаж и маркетинга также видели необходимость адаптироваться к новым условиям и идти в ногу со временем.

Как понять, что команда готова начать работать по Agile — чеклист:

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

Увеличение числа agile-команд — важный шаг для повышения гибкости бизнеса. Но не менее важно, как команды взаимодействуют с остальной организацией. Даже самые продвинутые agile-предприятия (Amazon, Google, Netflix, Bosch, SAP, Tesla и SpaceX) сочетают гибкий и традиционный подходы.

Чтобы бюрократические процедуры не мешали работе agile-команд, такие компании стремятся к изменениям, по крайней мере, в четырёх областях.

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

Руководству придётся прививать ценности и принципы Agile-методологии по всей компании. Именно поэтому Bosch разработали новые принципы лидерства: они хотели, чтобы все структуры были готовы к изменениям и понимали, что Agile станет центром культуры компании.

Внедрение agile-подхода требует интеграции рабочих потоков. Например, Amazon может запускать тысячи ПО в день, так как их архитектура изначально заточена под быстрых и частых релизов. Но многие компании, независимо количества разрабатываемого ПО, смогут выпускать всего несколько ПО в день.

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

Riot Games разработчик игр (в том числе очень популярной League of Legends) пересматривает общение между agile-командами и традиционными структурами (финансы, HR):

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

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

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

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

Компаниям, которые хотят развиваться по agile, важно нанимать классных специалистов и поощрять их. Более того, нужно строить в командах доверительные отношения и прививать общую ответственность за результаты. Это практически невозможно сделать без изменения работы HR-отдела.

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

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

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

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