Масштабирование Agile

Масштабирование Agile

Многим руководителям трудно представить, что небольшие Agile команды могут успешно выполнять крупномасштабные долгосрочные проекты. Но в принципе нет предела количеству Agile команд, которые вы можете создать, в зависимости от величины инициативы. Вы можете создать «команды команд», которые работают над соответствующими инициативами, – это очень масштабируемый подход. Например, работающий в сфере аэронавтики Saab имеет более 100 Agile команд, работающих над всем программным обеспечением, оборудованием и фюзеляжем истребителя Saab Gripen – товара стоимостью 43 миллиона долларов, который, безусловно, является одним из самых сложных продуктов в мире. В 7:30 утра каждая Agile команда проводит 15-минутный митинг, чтобы выявить препятствия, некоторые из которых не могут быть разрешены внутри этой команды. В 7:45 препятствия, требующие координации, переносятся на митинг команды команд, где лидеры команд работают, чтобы либо решить проблемы, либо передать их еще выше. В 8:45 управляющая команда получает от них список критических проблем, которые она должна решить, чтобы не отстать от графика. Все команды работают в общем ритме трехнедельных спринтов и координируются с помощью мастер-плана проекта, который рассматривается как живой документ, допускающий изменения. Кроме того, Saab совмещает традиционно разрозненные части организации, например, прохождение пилотами тестов на симуляторах с командами разработчиков. Результаты впечатляют: IHS Jane’s считает Gripen самым малозатратным военным самолетом в мире.

Прорыв

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишись на наш Telegram-канал и получи книгу в подарок!

Построение Agile во всем бизнесе

Увеличение числа Agile команд является важным шагом на пути повышения гибкости всего бизнеса. Но не менее важно то, как эти команды взаимодействуют с остальной организацией. Даже самые продвинутые Agile предприятия – например, Amazon, Spotify, Google, Netflix, Bosch, Saab, SAP, Salesforce, Riot Games, Tesla и SpaceX, – используют сочетание Agile команд и традиционных структур. Чтобы бюрократические функции не мешали работе Agile команд и не разрушали инновации, разработанные этими командами, компании постоянно стремятся к большим изменениям, по крайней мере, в четырех областях.

1. Ценности и принципы

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

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

2. Создание архитектуры

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

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

Генеральный директор Elon Musk говорит, что компания делает около 20 технических изменений в неделю для улучшения производства модели S, например, они внедрили новые батарейные блоки, обновленную программу безопасности и автопилота, программное обеспечение, которое автоматически поднимает руль и отодвигает сиденье для облегчения входа и выхода.

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

Со временем даже рутинные подразделения с иерархическими структурами, скорее всего, будут развивать Agile мышление. Конечно, финансовые отделы всегда будут управлять бюджетами, но им не нужно ставить под сомнение решения владельцев Agile инициатив. «Наш финансовый директор постоянно передает ответственность уполномоченным Agile команд», – говорит Ахмед Сидки, руководитель отдела управления развитием в Riot Games, – Я не должен управлять финансами компании. Вы, как руководители команд, должны это делать. Я присутствую здесь в качестве консультанта». В повседневной работе организации финансовые партнеры внедряются в каждую команду. Они не контролируют то, что команды делают или не делают. Они больше похожи на финансовых тренеров, которые задают сложные вопросы и предоставляют глубокие знания. Но в конечном итоге лидеры команд принимают решения, в соответствии с тем, что лучше для клиентов Riot».

Некоторые компании и отдельные люди могут испытывать трудности с принятием таких компромиссов. Сокращать свой контроль всегда страшно – пока вы этого не сделаете и не обнаружите, что люди стали счастливее, а показатели успеха утроились. В недавнем опросе Bain, охватывающем почти 1300 руководителей по всему миру, 95% респондентов согласились с утверждением: «Сегодняшние бизнес-лидеры должны доверять и расширять возможности людей, а не управлять ими» (лишь 5% с этим не согласны).

3. Привлечение талантов и мотивация

Компании, которые масштабируют Agile, нуждаются в привлечении звездных игроков и их мотивации, чтобы улучшить команды. (Относитесь к своим звездам несправедливо, и они сбегут от вас в модный стартап.) Компаниям также необходимо высвободить неизрасходованный потенциал остальных членов команды и создать причастность, доверие и общую ответственность за результаты. Практически невозможно сделать это без изменения процедур HR. Например, компания больше не может нанимать просто экспертов-одиночек; теперь она нуждается в экспертах, с энтузиазмом относящихся к совместной работе в команде. Она не может оценивать людей в зависимости от того, достигли ли они индивидуальных целей; теперь нужно оценивать их работу в Agile командах и смотреть, как оценивают друг друга члены команды. Ежегодная оценка эффективности обычно меняется на систему, которая обеспечивает обратную связь и коучинг каждые несколько недель или месяцев. Программы обучения и коучинга поощряют развитие межфункциональных навыков, адаптированных к потребностям отдельных сотрудников. Задания на работу реже применяются в самоуправляющихся командах, также уменьшается количество иерархических уровней. Но владельцы продуктов – люди, которые задают видение и владеют результатами Agile команды, – могут продолжать свое личное развитие, расширять свое влияние и увеличивать свою зарплату.

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

4. Ежегодный цикл планирования и бюджетирования

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

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

ВЫВОД

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

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

Подход Agile к тестированию и обучению часто описывается как инкрементный и итеративный, но не нужно ошибочно вводить инкрементные процессы развития для постепенного мышления. Например, SpaceX стремится использовать Agile инновации, чтобы начать доставку людей на Марс к 2024 году, с целью создания самодостаточной колонии на планете. Как это произойдет? Ну, люди в компании еще не знают … пока. Но у них есть видение, что это возможно, и у них есть понимание некоторых шагов. Они намерены значительно повысить надежность и сократить расходы, частично за счет многократного использования ракет, подобных самолетам. Они намерены улучшить двигатели для запуска ракет, которые смогут перевозить не менее 100 человек. Они планируют выяснить, как заправлять топливо в космосе.

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

Авторы: Darrell K. Rigby, Jeff Sutherland, Andy Noble
Источник