Введение Несбалансированная компания

Agile – подход к бизнесу, основанный на мобильных самоуправляющихся командах, которые внедряют инновации, – официально стал одним из главных направлений корпоративного управления. Почти в каждой крупной компании вы найдете несколько Agile-команд, работающих над улучшением клиентского опыта и бизнес-процессов. John Deere [1]использует методы Agile для разработки новых машин, USAA [2]– для изменения системы обслуживания клиентов, а 3M [3]– для проведения крупной интеграции путем присоединения отделов. Компания Bosch насчитывает 400 тысяч сотрудников. Вместе с тем Bosch еще и международный поставщик технологий и услуг, не побоявшийся внедрить принципы Agile для проведения своей пошаговой трансформации. Такие цифровые гиганты, как Amazon, Netflix и Spotify, включили Agile-методы в различные виды инновационной деятельности. В то же время Agile фактически захватил IT-отделы, являющиеся источником бесчисленных нововведений. Согласно последним подсчетам, 85 % разработчиков программного обеспечения используют в своей работе принципы Agile.[1]

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

Разумеется, это громкие заявления, но результаты исследований раз за разом демонстрируют, что Agile-команды внедряют инновации гораздо успешнее, чем команды, работающие традиционным способом. Улучшения достигаются быстро и с меньшими затратами. Растет удовлетворенность и вовлеченность сотрудников. Более того, компании должны применять Agile без необходимости создавать для этого отдельные бизнес-единицы или скрывать работу автономных групп от начальства. Agile-команды могут быть использованы в любом бизнесе и участвовать в модернизации любых функций организации, в том числе и функций головного офиса. Овладев основами Agile, компании будут готовы проводить масштабирование, создавая сотни отдельных команд или групп для крупных проектов. Например, авиастроительный бизнес Saab создал более сотни Agile-подразделений. Они работают над программным и аппаратным обеспечением, фюзеляжем для истребителя Gripen – изделия стоимостью 43 миллиона долларов, одного из самых сложных продуктов в мире. Агентство военной аналитики Janes считает Gripen самым экономичным военно-воздушным судном из существующих на сегодня.

Как вы видите, Agile-методы распространяются среди компаний, и Agile-команды в основном достигают своих целей. Что же тогда не так?

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

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

Результат неправильного использования – хаос, а не ожидаемые изменения. Ущерб наносится не просто какому-то отдельному бизнесу. Когда Agile применяют неверно, это почти всегда приводит к негативным последствиям. А негативные последствия – это волнующиеся клиенты, недовольные сотрудники и инвесторы-активисты, стремящиеся заменить управленческую команду. Новые менеджеры по понятным причинам скептически относятся к стратегиям, которые привели к снятию предыдущего руководства. Они, скорее всего, распустят Agile-команды и проведут серию увольнений. Экономический закон Грешема гласит, что плохие деньги вытесняют хорошие. То же самое можно сказать об Agile: плохой Agile вытесняет хороший. Если подобное начнет происходить слишком часто, Agile будет дискредитирован. В деловом мире все вернется на круги своя: неповоротливые корпорации будут вести безнадежную борьбу с дерзкими новичками за место на быстро меняющихся рынках.

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

Неправильный Agile

В фильме «Принцесса-невеста» мастер фехтования Иниго Монтойя упрекает хитрого Виццини в ответ на его очередное «Немыслимо!»: «Ты все время употребляешь это слово. Мне кажется, оно означает не то, что ты думаешь». То же самое и с Agile. Руководители часто не понимают, как он работает, в чем помогает преуспеть. Это не мешает им употреблять в своей речи терминологию Agile и делать предположения об этом подходе, которые просто не соответствуют действительности.

Иногда подобное происходит из-за того, что Agile-методы все еще относительно новы, и многие руководители плохо с ними знакомы. Например, часто можно услышать, что Agile полезен только для технологических инноваций и IT-отделов. Подобное утверждение стало бы новостью для организации National Public Radio, использовавшей Agile-методы для создания новых программ. Они были предназначены для людей, разрабатывающих истребитель Gripen, бытовую технику Haier, а также для многих компаний, использующих Agile для реорганизации цепочек поставок. Да, вначале Agile быстро распространился в IT-сфере. Но сегодня он широко и успешно используется во многих других видах деятельности, некоторые из которых содержат лишь незначительные технологические компоненты.

Другие ошибки, хотя нам неприятно об этом говорить, отражают определенную степень цинизма управленцев. Перед вами цитата из хорошо продуманного пресс-релиза, который Эдвард С. Ламперт (CEO компании Sears) опубликовал в 2017 году: «В дополнение к объявленной сегодня цели сокращения затрат мы продолжаем думать о том, как сделать нашу общую операционную модель и структуру капитала более гибкой…[4] и как стать инновационной компанией розничной торговли, ориентированной на опыт ее участников» [2]. Agile в этом контексте выступает как эвфемизм «увольнений». И Ламперт в своем заблуждении не одинок. Каждый месяц мы получаем письма с предложениями о работе, текст которых начинается примерно так: «Цель проекта (если вы решите взяться за него) – сократить в этом году операционные расходы на 30 %, одновременно переведя организацию на Agile-методы работы и цифровые технологии».

Отправители не понимают, что существует разница между массовыми хаотичными увольнениями и Agile. Во-первых, сокращения сотрудников, как правило, происходят сериями, связанными со стремительной реструктуризацией или ежегодными бюджетными циклами. Это диаметрально противоположно процессам непрерывного обучения и адаптации, которые предполагает концепция Agile. Во-вторых, старшие руководители обычно планируют увольнения за закрытыми дверями, а затем сообщают о новых структурах и фиксированных целях. Это несовместимо с Agile-принципом расширения прав и возможностей сотрудников, способствующего выявлению возможных улучшений. Хуже всего, что менеджеры, пытающиеся сочетать Agile с сокращениями, непреднамеренно демонстрируют поведение, отрицающее Agile. Они скорее создают предсказуемые командно-административные события, а не Agile-культуру «тестируй и учись». Более того, результаты исследований демонстрируют, что подобные решения высшего звена усугубляют неприятие риска и замедляют инновации. Люди с трудом осваивают новую работу. Руководители стараются контролировать ключевые операции независимо от того, что предписывает организационная структура. Они делают все возможное, чтобы сохранить свою должность в следующем году, если снова возникнут проблемы. Руководители пытаются создавать то, что умеют, но с меньшим количеством людей. А это не та среда, в которой Agile может успешно функционировать.

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

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

Agile, Agile повсюду

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

Чтобы не быть голословными, рассмотрим пример компании, которую назовем, скажем, MagicAgile. Это реальная организация, но мы не будем озвучивать ее настоящее имя, поскольку разговоры с руководителями были конфиденциальными. MagicAgile захотела стать похожей на таких цифровых гигантов, как Spotify[5]. По всей организации были созданы Agile-подразделения. Офисные помещения были перепроектированы так, чтобы сделать рабочие зоны открытыми. Были внедрены инновации в клиентский опыт и опыт сотрудников. В глазах проповедников Agile наша компания была живым примером. По крайней мере, так она выглядела, если игнорировать тот факт, что в 2018 и в начале 2019 года она потеряла около половины своей рыночной стоимости. Тут вы можете невозмутимо заявить, что без трансформации все было бы еще хуже или что биржевая стоимость ценных бумаг компании в любом случае не имеет значения. Но в откровенных разговорах с нами почти все руководители MagicAgile выражали разочарование, связанное с менее заметными результатами. Они говорили примерно следующее: «Agile создал проблему с руководством. У нас нет ни дисциплины, ни слаженности. Это хаос», «Мы зашли слишком далеко. Все говорят о лидерстве как служении и о психологической безопасности. Никому не позволено использовать слово менеджер, и все менеджеры затаились», «Непонятно, кто отвечает за прибыли и убытки», «Руководителей критикуют и игнорируют, когда мы пытаемся руководить бизнес-единицами», «Agile стал целью. Мы молимся у алтаря ложной церкви».

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

Сегодня мы понимаем ограничения бюрократии. Великий немецкий социолог Макс Вебер, который первым предложил систематическое описание бюрократии и хорошо понимал ее эффективность, предупреждал, что она может создать бездушную «железную клетку», которая запирает людей в обезличенных организациях и ограничивает их потенциал.[3] Он был прав: большинство людей сегодня работают в бюрократических структурах и чувствуют себя оторванными от своей работы. Широко распространенная среди молодежи привлекательность стартапов и малого бизнеса в сравнении с годами, потраченными на восхождение по корпоративным лестницам, отражает этот недостаток. Кроме того, бюрократии с трудом даются инновации. Она работает, когда ее организационные задачи – что и как делать – ясны, стабильны и предсказуемы. Инновации по определению не отвечают ни одному из этих критериев. Подобные ограничения способствовали формированию плохой репутации бюрократии и росту таких антибюрократических подходов, как Agile.

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

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

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

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

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

А сейчас займемся Agile

Фредерик Уинслоу Тейлор утверждал, что смог превратить бюрократическое управление из искусства в науку. Его исследования с секундомером считаются классикой в летописях бизнеса. В своей книге «Принципы научного менеджмента» 1911 года он изложил четыре фундаментальных принципа:

1. Менеджеры планируют работу, а рабочие ее выполняют;

2. Менеджеры проводят научный анализ наиболее эффективных способов выполнения работы;

3. Менеджеры проводят научный отбор и обучение правильных работников правильным видам работ;

4. Менеджеры строго контролируют выполнение работниками поставленных задач.[4]


В то время методы Тейлора подвергались жесткой критике за то, что он относился к людям, как к машинам. Но его подход прижился и пережил своего создателя. Даже сегодня во многих компаниях есть менеджеры и руководители, которые в душе являются тейлористами. А когда тейлористы пытаются внедрить Agile, это беда.

Часто получается так: высшее руководство планирует Agile-трансформацию своих подчиненных, а не самих себя. Компания создает проектный офис для управления программой с высокими полномочиями по принятию решений. Этот отдел составляет подробные бюджеты, определяет вехи и дорожные карты по выполнению проекта, дополненные диаграммами Ганта и строгими системами отчетности, чтобы обеспечить выполнение планов. Департамент создает массу Agile-команд, обычно возглавляемых тейлористами, только что прошедшими двухдневную подготовку по Agile. Если какая-то из команд добивается успеха, пусть и незначительного, проектный офис громко оповещает об этом в надежде убедить как внутреннюю, так и внешнюю аудиторию, что программа работает по плану. Тем временем само руководство продолжает действовать как раньше, контролируя все процессы и занимаясь микроменеджментом своих подчиненных, в число которых теперь входят члены Agile-команд. Эти управленцы часто указывают командам не только что делать, но и как это делать. В конце концов, разве не в этом заключается работа начальника?

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

Справедливости ради надо признать, что некоторые Agile-команды добиваются успеха даже на тейлористских предприятиях. Они скрывают свои действия от начальства и преуспевают скорее вопреки руководству, чем благодаря ему. Но настоящее Agile-изменение требует активного участия и поддержки главных лиц компании. Топ-менеджеры, которые действительно хотят масштабной Agile-трансформации, добиваются лучших результатов, если сами показывают, что надо делать, а не отправляют подчиненных на обучающие семинары. Они должны понимать Agile, любить его и использовать его методы в собственных командах. Есть известное высказывание Ганди: «Если хочешь изменить мир, изменись сам». Это справедливо и в отношении Agile.

Agile в качестве быстрого решения

Некоторые организации, столкнувшись с серьезными стратегическими угрозами и нуждаясь в радикальных переменах, проводят в некоторых подразделениях масштабные Agile-преобразования одним махом. Например, в 2015 году компания ING Netherlands[6] ожидала роста потребительского спроса на программное обеспечение и активное вторжение новых цифровых конкурентов в область цифровых технологий. Руководство решило действовать агрессивно. Были распущены организационные структуры, в том числе занимающиеся развитием IT, управлением продуктами, каналами распространения и маркетингом. По сути, их работа была упразднена. Затем создали небольшие «Agile-отряды» и от 3,5 тысяч сотрудников потребовали заявки на 2,5 тысячи измененных должностей. Около 40 % людей, вступающих в эти должности, были обязаны освоить новую работу. Всем требовалось серьезно преобразовать свое мышление.[5]

Опыт показывает, что с таким подходом связано множество проблем. Он сбивает с толку и травмирует организацию. Люди не знают, куда двигаться и что делать. Этот подход предполагает, что тысячи людей, большинство из которых не имеют знаний об Agile, внезапно его поймут и будут работать в соответствии с новыми принципами. Хотя радикально настроенные «новообращенные» демонстрировали успехи, общие результаты часто не соответствовали нереалистичным обещаниям. Цены на акции, включая акции ING, часто падали, иногда на 30 % и больше. За закрытыми дверями директора и их подчиненные дают более взвешенные оценки, которые обычно звучат примерно так: «Наши руководители и наша культура не были готовы к таким радикальным изменениям. Чем больше мы повторяли общепринятые клише «сорвать пластырь» и «сжечь корабли», тем больше мы в них верили. Но ни один из наших старших руководителей никогда не работал в Agile-среде. Мы не готовились к непредвиденным последствиям. Хуже того, мы потеряли нескольких прекрасных людей, которых заклеймили как препятствующих инновациям за попытку указать на эти последствия. Наш подход к гибкости был не очень гибким».

Более распространенный «инновационный» инструмент бюрократа – это копирование других. Конечно, для такого явления существуют и привлекательные названия: бенчмаркинг, конкурентная разведка или быстрый последователь. Но в конечном счете все сводится к повторению. Любимый объект подражания – компания Spotify, хорошо известная своим оригинальным Agile-лексиконом: отрядами, племенами, гильдиями и т. п. Иногда оказывается, что компании имитируют друг друга.

Такая практика соблазнительна. Пионеры, как Spotify, потратили годы на изучение и применение принципов Agile. Почему бы не повторить этот успех за шесть месяцев? Особенно заманчиво звучит идея, что все, что вам нужно сделать, – это скопировать организационную структуру и дизайн офиса первопроходца Agile. Если вы поменяете местами прямоугольники и их положение в организационной структуре, вы наверняка измените подход людей к работе. Постепенно подобные шаги приведут к новым итогам и результатам. Но что может пойти не так?

Что ж, давайте посмотрим. Во-первых, группы людей, как и человеческий организм, – это сложные системы, а значит, в разных средах переменные взаимодействуют по-разному. Лекарства, которые помогают одним пациентам, могут оказаться вредными для людей с другой генетикой, полом, возрастом или рационом. Менеджеры, пытающиеся внедрить структуры инновационных отделов одной компании в рамках совершенно другой организации, неизбежно получают плачевные результаты. Компания Spotify обладает достаточным опытом, чтобы на ее примере это понять. Она разработала инженерную модель в соответствии со своей уникальной культурой, извлекая выгоду из доверия и сотрудничества – двух ее главных ценностей. Технологические группы Spotify из-за их модульных продуктов и технологической архитектуры имеют меньше взаимозависимостей, чем подобные команды в большинстве организаций. Так что потенциальные подражатели, имеющие линейки продуктов, требующие тесной координации взаимозависимостей, часто получают «племенные» структуры, создающие хаос. Сотрудники Spotify постоянно предупреждают, что технологическая модель их компании непрерывно развивается и ее не следует копировать другим организациям или даже другим подразделениям внутри Spotify. Тем не менее, подражание продолжается.

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

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

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

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

Agile, который работает: дорожная карта книги

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

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

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


Глава 1. Как работает Agile. Немногие руководители наблюдали Agile-команду в действии. Еще меньше людей активно участвовали в работе такой команды, и почти никто из них не руководил ею. Без практического опыта руководителям трудно понять, что такое Agile. В этой главе мы расскажем историю, демонстрирующую Agile в действии. Мы объясним, откуда взялась эта философия, и опишем элементы, которые делают ее особым и эффективным методом внедрения инноваций.

Глава 2. Масштабирование Agile. Чем больше используете Agile, тем сложнее его применять. Но его использование также может дать исключительные результаты. Некоторые организации масштабируются, просто увеличивая число команд. Другие хотят создать настоящее Agile-предприятие. Такая компания сочетает широкое использование Agile-команд с некоторыми бюрократическими функциями и гармонизирует работу тех и других. Эта глава знакомит читателя с замечательной трансформацией компании Bosch и описывает шаги, которые должна предпринять организация при создании Agile-предприятия.

Глава 3. Какой уровень Agile вам нужен? Больше не всегда лучше. Для каждого бизнеса и для каждого вида деятельности существует оптимальный диапазон Agile. Но как определить этот диапазон? Компаниям следует искать правильный баланс между статичностью и хаосом, и для этого придется идти на необходимые компромиссы. Понадобится новый набор показателей, которые помогут определить, насколько гибкой (Agile) компания хочет стать, движется ли она в правильном направлении и какие ограничения препятствуют дальнейшему прогрессу. В этой главе мы покажем, как решать подобные проблемы с помощью Agile-методов.

Глава 4. Agile лидерство. Как верно подметил член правления Bosch Power Tools Хэнк Беккер, руководить Agile-предприятием – не то же самое, что управлять обычной компанией. Agile-руководители тратят меньше времени на анализ работы подчиненных. Они привносят свою ценность, адаптируя корпоративные стратегии, руководя критически важными Agile-подразделениями, проводя время с клиентами, наставляя отдельных людей и тренируя команды. Менять собственное поведение, перестраивать повседневную рутину и развивать новые навыки гораздо сложнее, чем учить этому других. Такая работа и ценится выше. В четвертой главе вы узнаете, как правильно ее выполнять.

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

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

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

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

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

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

Замечание об исследованиях

Истории об Agile-командах увлекательны и убедительны, иногда даже слишком. Проблема в том, что рассказами легко манипулировать, чтобы подтвердить точку зрения человека. Если вы не согласны, посмотрите, как по-разному CNN и Fox News сообщают об одних и тех же политических событиях. Предвзятость – хорошо известная проблема при поиске истины: люди склонны верить доказательствам, подтверждающим то, что они хотят услышать. Но история репрезентативна или же это статистическое отклонение? Как часто это происходит? Как часто люди делали все то же самое, но терпели неудачу?

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

Прежде чем писать эту книгу, мы постарались найти как можно больше данных о результатах применения Agile. Мы изучили множество описанных случаев, в том числе и случаи нескольких сотен собственных клиентов. Мы проанализировали корреляции по диагностическим опросам, проведенным тысячами практиков Agile, которые отслеживают свой прогресс с помощью нашего коэффициента гибкости Бейна. Чтобы быть максимально объективными, мы также собрали и проанализировали 70 отчетов сторонних исследователей. (Полный список отчетов включен в приложение С, чтобы вы могли ознакомиться с любым из них или сразу со всеми). Это журнальные статьи, книги, правительственные документы, научные диссертации, материалы конференций, консалтинговые и корпоративные исследования и т. д. Некоторые отчеты регулярно обновляются на протяжении многих лет. В других объединены выводы нескольких исследователей. Некоторые более академичные и строгие, чем другие. Мы, вероятно, пропустили какие-то сообщения, что может обидеть их составителей. За это мы приносим извинения и обещаем продолжать расширять и обновлять нашу базу данных.

В целом, мы были воодушевлены тем, что нашлось так много эмпирических данных. По нашему мнению, это убедительное доказательство того, что использование Agile на уровне команды и при масштабировании до уровня предприятия способствует улучшению результатов (Рис. 1–1). Даже без контроля качества выполнения Agile или отбрасывая неудобные точки ввода данных мы находим мало исследований, предполагающих, что Agile-подходы в среднем вредят результатам. Вот наши более конкретные выводы:



Больше инноваций – лучше результаты. Если вы разочарованы итогами работы вашей компании, осознаете ее несбалансированность и задаетесь вопросом, следует ли внедрять меньше или больше нововведений, велика вероятность, что правильный ответ будет «больше». Более 90 % проанализированных нами исследований показывают, что нововведения улучшают результаты деятельности. Ни одно не показывает, что они вредят. Просто некоторые компании внедряют их так много, что происходит снижение доходности. Опыт показывает, что цены на акции могут не отражать будущие выгоды от новшеств. Но известно, что эффективность фондовых рынков проявляется со временем, а в краткосрочной перспективе оценивается неточно.

Agile-инновации даже лучше, чем обычные инновации. Мы нашли 21 отчет об исследованиях на эту тему. Три четверти из них утверждают, что Agile – это лучший способ внедрять технологии, и только 10 % приходят к выводу, что Agile не помог. Важно отметить, что Agile-методы хоть и могут повысить шансы на успех, они его не гарантируют. В одном из самых популярных отчетов, исследовании хаоса (CHAOS REPORT) Standish Group[7], проводится сравнение показателей успеха Agile и традиционных подходов в IT-проектах с 1994 года. На сегодня у этих исследователей есть база данных по более чем 50 000 проектам. Оказалось, что три пятых Agile-проектов имеют больше шансов на успех (42 % против 26 %) и лишь одна треть – на провал (8 % против 21 %). Это впечатляет, но 42 % успеха – не 100 %, и эти цифры отражают ситуации, при которых реализуется достаточное количество Agile-проектов, чтобы вступили в силу законы больших чисел.[6]

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

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