Что значит масштабировать Agile?
Есть очень простое определение масштабирования Agile: это постоянное создание новых Agile-команд. Увеличить их число до пятидесяти, ста или более. Расширить сферу применения Agile, чтобы Agile-команды функционировали в разных частях организации. Научиться использовать группы команд, занимающиеся очень большими проектами. Мы встретили много разных примеров подобного масштабирования, и большая часть комментариев касается успешной реализации этого подхода. Мы называем это масштабированный Agile, и на данный момент как раз-таки его обычно реализуют в типичных крупных организациях.
Но есть и другое определение масштабирования Agile. Это то, что еще предстоит большинству компаний. Мы называем это созданием Agile-предприятия, и в некотором смысле именно об этом и идет речь в нашей книге. Масштабированный Agile фокусируется на повышении эффективности Agile-команд, позволяя бюрократии и инновации сосуществовать. Agile-предприятия, напротив, фокусируются на создании гибких бизнес-систем: они превращают бюрократию и инновационные действия в симбиотических партнеров, сотрудничающих ради достижения превосходных результатов. В последующих главах будет подробно обсуждаться вопрос, как далеко и как быстро следует продвигаться. Не обойдем стороной и множественные изменения в поведении, процессах и операциях, необходимые для создания Agile-предприятия. В этих главах мы постараемся охватить все, начиная с преобразования IT и изменения бюджетного процесса и заканчивая модернизацией системы управления кадровым потенциалом и системой оплаты труда. В настоящей главе мы ставим перед собой более скромную, но не менее важную цель. Мы хотим сделать общий обзор того, что связано с созданием Agile-предприятия, и показать, чем оно отличается от использования масштабированного Agile. Мы также хотим выяснить, почему компания может захотеть заняться столь амбициозным и порой опасным делом.
Масштабированный Agile
Компания, которая стремится внедрить масштабированный Agile, скорее всего, останется бюрократической в своем фундаментальном подходе к бизнесу. Как правило, клиент, которого она стремится удовлетворить, – это акционер. Основная цель состоит в том, чтобы создать достаточное число Agile-команд для улучшения финансовых результатов. Чтобы обеспечить прибыльность программы, руководство может сочетать меры по сокращению расходов, включая увольнения, с поддержкой Agile-команд. Преобразованием обычно руководит отдел управления программой, точно так, как до этого другими инициативами руководили целевые группы. Управление программой заключается в изменении поведения людей – создании Agile-команд, продвижении сторонников или увольнении людей, которые активно сопротивляются трансформации. Руководящий состав также, как правило, берет на себя ответственность за то, чтобы не дать Agile-команде сбиться с пути или выйти за рамки бюджета. Через пару лет появится гораздо больше Agile-команд, и они, скорее всего, будут довольно эффективно координировать свои действия. Тем не менее, они почти наверняка будут работать в рамках бюрократической системы корпоративного управления, операций, поддержки и контроля – системы, которая работает почти так же, как работала в течение десятилетий.
Ранее мы определили некоторые из подобных практик как подводные камни, которых следует избегать, – это и считается ловушкой, если вы хотите создать настоящее Agile-предприятие. Но масштабированный Agile не всегда терпит поражение и для некоторых компаний он может стать правильным выбором. Процесс создания все новых и новых Agile-команд управляем в рамках традиционных процессов руководства, и большинство препятствий можно преодолеть, творчески используя обходные пути. Топ-менеджеры могут контролировать работу нескольких десятков Agile-команд, не причиняя вреда их производительности и не подрывая моральный дух. Поскольку Agile-группы почти всегда работают лучше, чем традиционные проектные команды, результаты, как правило, улучшаются. И все же такой подход сопряжен с серьезными рисками. Со временем части организации, не использующие Agile, могут начать жаловаться. Сотрудникам этих подразделений может показаться, что Agile-команды крадут лучших людей, перехватывают деньги, которые могут быть использованы в других подразделениях, игнорируют процедуры составления бюджета, ставят под угрозу хорошую практику управления и в целом подвергают компанию риску. Возникающий в результате разлад может вынудить организацию вернуться к более традиционным способам ведения дел, пожертвовав всеми достигнутыми успехами. Существует также «стоимость выбора»: компания, которая ограничивает себя масштабированным Agile, отказывается от потенциальных выгод создания Agile-предприятия.
Но самая большая проблема – и противоречащая здравому смыслу – заключается в следующем: хотя Agile-команды разрабатывают инновации лучше и быстрее, чем это происходило прежде, руководители, скорее всего, обнаружат, что общая скорость внедрения инноваций в компании не растет. Разобравшись, они поймут концепцию эффективности потока.
Время, которое требуется Agile-команде, чтобы осуществить инновацию, определяется двумя факторами: временем, необходимым для работы над инновацией, и временем, потраченным на ожидание других. Время ожидания включает в себя задержки, вызванные такими операционными процессами, как календари стратегического планирования, процессы согласования решений, циклы бюджетирования и финансирования, графики выпуска программного обеспечения, правовые или нормативные ограничения, процессы распределения персонала и десятки других факторов. Эффективность потока компании рассчитывается путем деления рабочего времени на сумму рабочего времени плюс время ожидания (Рис. 2–1). Эмпирические данные показывают, что эффективность потока для большинства компаний редко превышает 15–20 %. Таким образом, даже если благодаря Agile скорость работы увеличится на одну пятую, общая скорость внедрения инноваций на предприятии может увеличиться только на 3 или 4 %. Это едва заметная разница. Более того, когда компании увольняют оперативный и обслуживающий персонал, чтобы платить за Agile-команды без изменения бизнес-процессов, остается меньше людей для выполнения того же количества работы.
Это приводит к снижению скорости, длинным очередям, длительному ожиданию и большему количеству незавершенной работы. Что еще хуже, менеджеры отчаянно ищут способы оптимизировать использование ресурсов и снизить затраты, поэтому они заполняют время, поручая людям дополнительные проекты. Это приводит к многозадачности, что увеличивает затраты на переключение, снижает производительность, увеличивает время ожидания и еще больше замедляет циклы разработки. В конце концов, скорость внедрения инноваций может даже снизиться.
Вот показательный пример и реальный аналог опыта Irresistible Snacks. Крупная финансовая компания, которую мы исследовали, запустила пилотный проект по созданию следующего мобильного приложения с использованием Agile-методов. Конечно, первым шагом было формирование команды. Для этого надо было направить бюджетную заявку на разрешение и финансирование проекта. Она вошла в пакет документов, предлагаемых к утверждению в следующем процессе годового планирования. После нескольких месяцев анализа компания наконец одобрила финансирование. В ходе пилотного проекта было разработано эффективное приложение, которое высоко оценили клиенты, и команда гордилась своей работой. Но прежде чем выпускать приложение, необходимо было провести оценку его уязвимости в рамках традиционного каскадного процесса. Это длительная процедура, в ходе которой тестируется документирование, функциональность, эффективность и стандартизация компьютерного кода, и очередь на нее была длинной. Затем приложение надо было интегрировать в основные IT-системы, что означало еще один каскадный процесс с шестимесячным или девятимесячным лагом. В итоге общее время выпуска сократилось совсем незначительно.
Так как же справляться с такими серьезными вызовами? Это цель Agile-предприятия.
Agile-предприятие
Agile-предприятие – это нечто большее, чем просто совокупность команд. Это тщательно сбалансированные операционные модели, которые используют Agile-методы для (1) надежного и эффективного ведения бизнеса, (2) его изменения с целью извлечения пользы из непредсказуемых возможностей и (3) гармонизации двух видов деятельности. Поэтому руководители, стремящиеся создать такое предприятие, подходят к процессу масштабирования с другим мышлением. Они не пытаются отделить Agile-команды от остальной организации, как если бы эти две группы были врагами. Они также не пытаются поместить всех сотрудников в Agile-группы. Хотя инновационные Agile-команды – это важный элемент Agile-предприятия, в них обычно входит только 10–50 % сотрудников. Большая часть работы и большинство людей в подобных системах сосредоточены на управлении бизнесом – операциях, поддержке и контроле.
Кроме того, в таком предприятии руководители рассматривают сам процесс масштабирования как Agile-инициативу – фактически как самую важную из всех Agile-инициатив. Руководители высшего звена управляют переходом как Agile-команда. Они понимают, что подобные оптимизации – это продукты непрерывного совершенствования, а не проекты с ожидаемыми результатами или фиксированными сроками завершения. Они рассматривают сотрудников не как подчиненных, сопротивляющихся переменам, а как клиентов, чье участие и обратная связь имеют решающее значение для успеха. Руководящая команда устанавливает приоритеты и последовательность возможностей для улучшения опыта этих клиентов и повышения их удовлетворенности. Руководители занимаются решением проблем и устранением препятствий, а не делегируют эту работу подчиненным.
Компания Bosch, ведущий мировой поставщик технологий и услуг с более чем 400 000 сотрудников и деятельностью в шестидесяти с лишним странах, приняла этот подход. Когда руководители начали понимать, что традиционное управление «сверху вниз» неэффективно в быстро меняющемся глобализированном мире, организация стала одним из первых последователей Agile-методов. Но оказалось, что разные сферы бизнеса требовали разных подходов, и первая попытка Bosch масштабировать Agile привела к культуре раздора, в которой полные энтузиазма новые подразделения управлялись Agile-командами, а традиционные функции оставались в стороне, что ставило под угрозу задачи целостной трансформации. В 2015 году члены правления во главе с CEO Фолькмаром Деннером решили выстроить единый и целостный подход к Agile-командам. Правление выступило в качестве руководящего комитета, а руководителем работ был назначен Феликс Иероними, инженер-программист, ставший экспертом Agile.