акже облегчают для членов команды синхронизацию длинных и медленных процессов с быстрыми.
Участник группы, являющийся владельцем инициативы, в конечном счете несет ответственность за создание ценности продукта для клиентов (включая внутренних клиентов и будущих пользователей) и бизнеса. Как правило, это представитель бизнес-функции, которая занимается работой с командой и координацией действий с ключевыми заинтересованными сторонами: клиентами, высшими руководителями и бизнес-менеджерами. Владелец инициативы может использовать такие методы, как дизайн-мышление или краудсорсинг, чтобы создать полный перечень перспективных возможностей. Затем он постоянно и безжалостно ранжирует этот перечень в соответствии с последними оценками важности тех или иных действий для внутренних или внешних клиентов и компании. Он не указывает команде, кто и что должен делать и сколько времени займет выполнение задач. Члены команды сами создают простую дорожную карту и детально планируют только те виды деятельности, в которых не ожидается изменений. Они разбивают наиболее приоритетные задачи на небольшие модули, решают, какой объем работы они возьмут на себя и как будут ее выполнять. Кроме того, участники четко определяют понятие «выполнено», а затем начинают создавать рабочие версии продукта в рамках спринтов. Процессом руководит фасилитатор (часто это обученный scrum-мастер). Он защищает команду от отвлекающих факторов и помогает ей задействовать коллективный разум.
Процесс полностью прозрачен. Члены команды ежедневно проводят краткие координационные совещания для анализа прогресса и выявления препятствий. Они разрешают разногласия путем экспериментов и обратной связи, а не путем бесконечных дебатов или апелляций к начальству. В течение короткого периода времени они с участием нескольких клиентов тестируют небольшие рабочие прототипы всего продуктового предложения или его части. Если продукт нравится клиентам, прототип может быть выпущен немедленно, даже если кому-то из старших руководителей он не слишком нравится или кто-то считает, что нужно больше деталей. Затем команда проводит мозговой штурм, как улучшить будущие циклы, и готовится к работе над следующим приоритетом.
В сравнении с используемыми в менеджменте традиционными подходами, Agile имеет ряд важных преимуществ, и все из них изучены и описаны. Он повышает производительность команды и удовлетворенность сотрудников. Agile сводит к минимуму потерю времени, связанную с ненужными совещаниями, повторяющимся планированием, избыточной документацией, дефектами качества и малоценными характеристиками продукта. Повышая наглядность и постоянно адаптируясь к меняющимся приоритетам клиентов, метод приумножает их вовлеченность и удовлетворенность, быстрее и более предсказуемо выводит на рынок наиболее ценные продукты и функции, а также снижает риски. Благодаря тому, что в команде сотрудничают представители разных направлений деятельности, этот подход обогащает опыт организации и укрепляет взаимное доверие и уважение. Наконец, резко сокращая время, затрачиваемое на микроуправление функциональными проектами, Agile позволяет старшим менеджерам сосредоточенно заниматься той ценной работой, которую могут выполнять только они: созданием и корректировкой стратегического видения; приоритезацией стратегических инициатив; упрощением и фокусировкой работы; назначением нужных людей для выполнения поставленных задач; расширением межфункционального сотрудничества и устранением препятствий на пути прогресса.
Практики Agile чрезвычайно скептически относятся к способности менеджеров предсказывать, управлять и контролировать инновационные решения, особенно когда неясно, что и как нужно делать. В качестве мысленного эксперимента представьте, что вам поручено разработать маршрут самоуправляемого автомобиля из Миннесоты во Флориду. У вас будет два варианта.
Первый – создать детерминированную модель транспортного средства. Можно детально изучить дороги между Миннесотой и Флоридой, спрогнозировать каждый изгиб и поворот, изменение сигнала светофора, пересечение дороги пешеходом или оленем, дорожно-транспортные происшествия и погодные условия. Если автомобиль попадает в аварию во время пробного прогона (а это неизбежно), вам предложат еще поработать и улучшить свои навыки прогнозирования. Но шансы, что дополнительная работа решит проблему, невелики. Если бы транспортное средство двигалось внутри трубы, возможно, модель прогнозирования и планирования сработала бы. В реальном мире все усложняется очень быстро.
Другой подход заключается в программировании автомобиля на адаптацию к изменяющимся условиям. Выясните, почему кто-то вообще может захотеть поехать из Миннесоты во Флориду. Если ураганные условия делают Флориду слишком опасной, подумайте о перенаправлении поездки в Калифорнию. Затем спрогнозируйте возможные ситуации, разработайте способы их измерения, создайте датчики для их отслеживания и запрограммируйте соответствующие реакции на ситуации. Соберите данные из метеорологических центров, с дорожных мониторов и от других водителей. Передайте информацию на те же датчики вашего автомобиля. «Я приближаюсь к перекрестку, надо обязательно остановиться на светофоре». Если петли обратной связи достаточно коротки и чувствительны, переходы будут плавными и удобными, а не крутыми и резкими. Вот что такое Agile – учиться по ходу дела.
1. Agile-команда – это основа Agile. Если вы не понимаете, как работает такая команда, вам будет трудно масштабироваться до уровня предприятия.
2. Agile-команды считают, что отзывы клиентов лучше помогают определить, какие действия для внедрения инновации важны и как эти шаги лучше адаптировать.
3. Agile-команды используют спринты не для того, чтобы заставить людей работать более напряженно или быстро. Они делают это, чтобы моментально получать отзывы от реальных клиентов (внешних и внутренних) о ценности продукта.
4. Бюрократы будут препятствовать отказу от контроля до тех пор, пока не разрешат эксперименты в контролируемых условиях и не обнаружат, что показатели успеха утроились – и что клиенты, сотрудники и акционеры довольны.
5. Опрометчиво пытаться прогнозировать, управлять и контролировать инновации там, где нет ясности относительно конечного продукта и способа его получения.
Глава 2Масштабирование Agile
В авиастроительной компании Saab работает более ста Agile-команд, занимающихся разработкой программного обеспечения, оборудования и фюзеляжа для истребителя Gripen, фантастически сложного продукта стоимостью 43 миллиона долларов. В 7:30 утра каждая команда, работающая на переднем плане, проводит пятнадцатиминутное собрание, чтобы обсудить имеющиеся проблемы. Некоторые из них невозможно решить в рамках команды. В 7:45 вопросы, требующие координации, передаются в вышестоящую группу, руководители которой либо решают их, либо передают дальше по иерархической лестнице. Процесс продолжается, и к 8:45 управляющая команда получает перечень критически важных вопросов, которые необходимо решить, чтобы можно было продолжать работу в нужном направлении. Saab Aeronautics также координирует деятельность своих команд с помощью трехнедельных спринтов, генерального плана проекта (это актуализируемый документ) и совместного использования различных традиционных частей организации – например, проведения пилотного тестирования и использования средств моделирования в командах разработчиков. Как уже было сказано, считается, что конечный продукт станет самым экономичным военным самолетом в мире.
Компания SAP SE, производящая корпоративное программное обеспечение, одна из первых провела масштабирование Agile, запустив этот процесс десять лет назад. Ее руководители сначала внедрили Agile в своих подразделениях по разработке программного обеспечения (сегменте, максимально ориентированном на клиента), где смогли протестировать и усовершенствовать свой подход. Они создали небольшую группу консультантов для обучения, коучинга и внедрения нового способа работы, а также систему отслеживания результатов, чтобы все могли знать о достижениях команд. «Демонстрация конкретных примеров впечатляющего роста производительности благодаря Agile вызывала все больший интерес в организации», – рассказывал Себастьян Вагнер, менеджер-консультант группы.[1] В течение следующих двух лет компания внедрила Agile в более чем 80 % своих групп разработчиков, создав более двух тысяч команд. Персонал отделов продаж и маркетинга осознал необходимость адаптироваться, чтобы не отставать. Когда был достигнут прогресс на внешней стороне, пришло время действовать бэк-офису, поэтому SAP перевела на Agile группу, работающую над внутренними IT-системами.
На момент написания книги в группе компаний USAA работало несколько сотен Agile-команд, и их число планировалось увеличить. USAA – финансовая организация, которая специализируется на обслуживании американских военнослужащих, связывает деятельность Agile-команд с людьми, ответственными за бизнес-единицы и продуктовые линейки. Цель состоит в том, чтобы менеджеры, ответственные за конкретные части отчета о прибылях и убытках, понимали, какое влияние на их результаты могут оказать кросс-функциональные команды. В компании есть руководители высшего звена, которые выступают в качестве генеральных менеджеров в каждом направлении бизнеса и полностью отвечают за результаты деятельности. Что касается выполнения значительной части работы, они полагаются на команды, действующие в рамках всей организации. USAA также зависит от технологий и цифровых ресурсов, предоставляемых их владельцам опыт; цель состоит в том, чтобы обеспечить бизнес-руководителей всеми необходимыми ресурсами для достижения результатов, которых они обязались достичь.
В течение последних десяти лет руководители, имеющие опыт работы с Agile-командами или слышавшие о них, начали задавать серьезные вопросы. Что, если компания создаст десятки, сотни или даже тысячи Agile-команд по всей организации? Могут ли целые сегменты бизнеса научиться работать таким образом? Повысит ли масштабирование Agile корпоративную производительность так, как методы Agile повышают производительность отдельных команд? Такие разные компании, как 3M, Amazon, Bosch, Dell, Google, Haier, ING, Lego, Microsoft, Netflix, PayPal, Royal Bank of Scotland, Riot Games, Salesforce, Spotify и Target, увеличили масштаб и охват своих Agile-команд. Мы работали со многими из них и изучали их опыт. Хотя в целом результаты впечатляют, огромное удивление вызывает разнообразие в подходах компаний к достижению цели и даже к определению, что значит масштабировать Agile.