Вы, наверное, задаетесь вопросом: «Как мне оплатить эти команды?» Решение в большинстве случаев заключается в сокращении непродуктивной инновационной деятельности и преобразовании непрерывных инновационных инициатив в Agile-команды. Часто таксономия показывает, что около трети существующих инновационных команд работает над тем, чего клиенты не хотят, или тем, что команды не смогут предоставить. Использовавшиеся ранее процессы не давали возможности остановить такую деятельность, пока не будет потрачен бюджет. Agile позволяет это изменить. Для команд, которые продолжат работать, методы Agile должны повысить производительность по крайней мере на 20 %, а иногда и значительно сильнее. По мере того как Agile-команды будут переходить к преобразованию бизнес-процессов и технологий, эффективность будет расти.
Определение последовательности перехода
Используя таксономию, руководящая команда устанавливает приоритеты и последовательность инициатив. Руководители должны рассмотреть множество критериев, включая стратегическую важность, бюджетные ограничения, наличие персонала, эффективность инвестиций, стоимость задержек, уровни риска и взаимозависимость между командами. Наиболее серьезными – и наиболее часто игнорируемыми – являются проблемы, с которыми сталкиваются клиенты и сотрудники, с одной стороны, и возможности и ограничения организации – с другой. Учет всех этих аспектов позволяет определить правильный баланс между скоростью создания и количеством команд, с которыми организация может работать одновременно.
Некоторые компании, столкнувшись с серьезными стратегическими угрозами и нуждаясь в радикальных переменах, провели в некоторых подразделениях масштабные Agile-преобразования «одним махом». Среди них была компания ING, которую мы упоминали во введении. Барт Шлатман, прежний операционный директор, размышлял об этом периоде в интервью:
«Я помню январь 2015 года, когда мы объявили, что все сотрудники в штаб-квартире будут переведены на “мобильность”; фактически это означало, что они остались без работы. Мы попросили каждого вновь подать заявление о приеме на работу в новой организации. Процесс отбора был интенсивным, и мы больше внимания уделяли культуре и мышлению кандидатов, а не их знаниям или опыту. Каждый из наших сегодняшних 2 500 сотрудников прошел отбор, и почти 40 % из них занимают не ту должность, которую занимали раньше. Да, мы расстались с теми, у кого были хорошие знания, но отсутствовало правильное мышление; ведь знания можно восполнить, если у человека есть способности».[3]
Понятно, что Барт несколько приукрашивает то, как все происходило. Но вы представляете, какой ужас и боль эта инициатива должна была вызвать у персонала? Зачем начинать с такого рискованного и дорогостоящего шага? При подобном подходе акцент делается скорее на экономии затрат, а не на инновациях и росте. Внедрение новых методов, когда люди опасаются за свои рабочие места, а 40 % из них получают новую должность, – это довольно драматичное начало проекта. Уже не говоря о том, что такие действия команды руководителей прямо противоречат ценностям Agile.
Радикальные переходы – вообще дело трудное. Нужна абсолютная приверженность руководства, восприимчивая культура, достаточное число талантливых и опытных практиков Agile, чтобы укомплектовать сотни команд, не истощая другие направления деятельности, и предписывающая техническая документация для согласования подходов всех участников. Подобные переходы также требуют высокой устойчивости к риску, наряду с планами на случай непредвиденных срывов. Компаниям, которым этого не хватает, скорее следует внедрять Agile в ходе последовательных шагов, когда каждое подразделение соотносит реализацию со своими возможностями. Имея начальный вариант видения и упорядоченный бэклог, руководители высшего звена могут создать начальную группу Agile-команд, собрать данные о создаваемой ими ценности и ограничениях, с которыми они сталкиваются, а затем решить, следует ли делать следующий шаг, и если да, то когда и как. Более подробно вопрос «как далеко и как быстро» будет рассмотрен в Главе 3.
Планирование взаимозависимостей
Одна из особенностей Agile заключается в том, что сложные задачи разбиваются на более мелкие и более управляемые модули. Это главная причина, почему Agile-предприятию нужно так много Agile-команд. Следовательно, основной задачей становится координация и интеграция таких модулей, а для этого требуется полная прозрачность, когда каждая группа знает, что делают другие и какие могут быть последствия. В бюрократических организациях указания и согласования поступают из центрального узла. Agile-предприятие, напротив, должно создать сеть узлов, способных работать друг с другом без наличия центрального. Вот почему так важна прозрачность. Технологические системы могут помочь, но часто необходимы регулярные личные коммуникации.
Также иногда может быть полезен небольшой офис управления программой, как для координации, так и в качестве дополнения к правлению. Но надо помнить, что цель – это Agile-предприятие. Офис управления программой или офис трансформации не должен становиться Agile-полицией или посредником между руководителями и их командами. Он должен оставаться компактным и сервис-ориентированным, наблюдать за результатами Agile-команд и сообщать руководящей команде о возможностях совершенствования. Если переход действительно так важен, как мы утверждаем, правление должно уделить ему значительное время, как это было в Bosch. Офис управления программой может также быть дополнен центром передового опыта, связанным с Agile и ориентированным в первую очередь на обучение и коучинг Agile-команд. Тренеры и коучи могут быть доступны всем, но их следует привлекать только по просьбе тех групп, которым потребуются их услуги.
Начиная переход, слишком многие компании совершают ошибку, стремясь к легким победам. Они помещают команды в изолированные «инкубаторы», они вмешиваются, предлагая легкие обходные пути в случае появления системных препятствий. Такая забота увеличивает шансы команды на успех, но не создает среды для обучения и не производит организационные изменения, необходимые для масштабирования Agile до десятков или сотен команд. Первые Agile-команды компании несут бремя судьбы. Их тестирование, как и тестирование любого прототипа, должно отражать различные реальные условия. Наиболее успешные компании сосредоточиваются на особо важном клиентском опыте, который вызывает наибольшее огорчение у функциональных подразделений.
Тем не менее, ни одну Agile-команду нельзя запускать в работу до тех пор, пока она не будет готова. Готовность не означает детального планирования и гарантированного успеха. Это означает, что команда:
• сосредоточена на крупных возможностях развития бизнеса, когда многое поставлено на карту;
• отвечает за конкретные результаты;
• уполномочена работать автономно, руководствуясь четкими правами на принятие решений;
• обеспечена необходимыми ресурсами и располагает небольшой группой междисциплинарных экспертов, вдохновленных этой возможностью;
• привержена применению ценностей, принципов и практик Agile;
• имеет возможность тесно сотрудничать с клиентами;
• способна оперативно создавать прототипы и петли быстрой обратной связи;
• пользуется поддержкой руководителей высшего звена, готовых устранять препятствия и способствовать признанию работы команды.
Какой бы ни была скорость или конечная точка, результаты начнут проявляться быстро. Разве что для появления финансовых результатов может потребоваться некоторое время. Джефф Безос считает, что Amazon начинает получать дивиденды от большинства инициатив через 5–7 лет, но позитивные изменения в поведении клиентов и в решении проблем команды – это раннее свидетельство, что организация на правильном пути. В начале своей Agile-инициативы группа передовых технологий в компании 3M Health Information Systems создавала от восьми до десяти команд каждый месяц или два; через пару лет было создано и функционировало более девяноста команд. Лаборатория корпоративных исследовательских систем 3M (Corporate Research Systems Lab) начала работать позже, но за три месяца создала двадцать команд. «Внедрение Agile уже позволило ускорить поставки продуктов и выпустить бета-версию приложения на шесть месяцев раньше, чем первоначально планировалось», – рассказывает Тэмми Спэрроу, старший менеджер программ в 3M Health Information Systems. [4]
Согласование бюрократии и инноваций
Чем больше команд создает компания, тем выше вероятность возникновения трений между частями организации, основанных на принципах Agile и принципах бюрократии. До недавнего времени считалось, что два этих элемента следует разделять, потому что бюрократия всегда будет стремиться подавить действия по внедрению инноваций. Вот почему многие мечтали о руководителях-амбидекстрах, одинаково искусных в управлении бизнесом и в его изменении. Вот почему многие организации создавали автономные группы (skunkworks) или отдельные операционные единицы для новых агрессивных предприятий. К сожалению, таких руководителей мало, и молодые skunkworks часто погибают еще в зародыше.
Однако Agile-предприятие должно обеспечивать согласованность и взаимодополняемость между операциями и инновациями, и компании, продвинувшиеся на пути внедрения Agile достаточно далеко, этому научились. Например, как мы увидим в Главе 8, компания Amazon создала крупные инновационные подразделения в самом сердце своей уже существующей организации; она также структурировала бюрократические функции так, чтобы их деятельность была согласована с внедрением инноваций. Обычно Agile-предприятия полагаются по крайней мере на три инструмента для синхронизации этих двух компонентов.
Один из лучших способов преодолеть разногласия и направить организацию на правильный путь – это включение оперативного персонала в Agile-команды. Сделайте нескольких рядовых сотрудников штатными членами команд, которым нужен их опыт. Используйте других в качестве профильных специалистов, к которым Agile-команды могут обращаться со срочными запросами. Создайте Agile-команды с большим количеством рядовых сотрудников, чтобы критически рассмотреть действующие операционные стандарты и преобразовать бизнес-процессы и технологии для создания новых стандартов эффективности и качества. Укрепляйте доверие и сотрудничество между инноваторами и работниками производства. Сделайте так, чтобы Agile-инновации внедрялись и эффективно масштабировались в реальных условиях эксплуатации. По мере того как сотрудники будут больше узнавать о ценностях и принципах Agile, они начнут рассматривать возмож