Текст книги "Agile, который работает. Как правильно трансформировать бизнес во времена радикальных перемен"

Почему Agile?

Компания Irresistible Snacks, Брайан и Agile-команда, которую он возглавлял, конечно, вымышлены. История придумана, она основана на историях сотен компаний и команд, которые мы наблюдали. Но вымысел отражает два набора фактов об Agile.

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

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

Происхождение Agile

Некоторые историки прослеживают Agile-методологию вплоть до формулирования научного метода, предложенного Фрэнсисом Бэконом в 1620 году. На наш взгляд, было бы более разумно считать отправной точкой 1930-е годы, когда физик и статистик Уолтер Шухарт из Лаборатории Белла (Bell Labs) начал применять циклы непрерывного совершенствования (спецификация-производство-контроль) для улучшения продуктов и процессов. В 1938 году У. Эдвардс Деминг заинтересовался работой Шухарта и популяризировал ее с помощью хорошо известного на сегодняшний день цикла PDSA (plan-do-study-act, планирование-действие-изучение-корректировка).

В 1986 году Икудзиро Нонака и его соавтор Хиротака Такеути опубликовали в журнале Harvard Business Review статью под названием «Разработка нового продукта. Новые правила игры» (The New Product Development Game)^[1]. Изучая компании, внедряющие инновации гораздо быстрее, чем конкуренты, авторы выявили командно-ориентированный метод, изменивший процесс проектирования и разработки таких продуктов, как копировальные аппараты Fuji-Xerox, автомобильные двигатели Honda и фотоаппараты Canon. Вместо того чтобы следовать традиционным методам разработки продукта в виде «эстафеты» (одна группа функциональных специалистов передает выполненную работу следующей), эти компании использовали подход, который Такеути и Нонака назвали «регбийным» – «команда пытается пройти всю дистанцию как единое целое, передавая мяч друг другу».^[1]

В 1993 году Джефф Сазерленд [10]10
  Джефф Сазерленд (род. 20 июня 1940 г.) – американский программист, участвовал в разработке методологии Scrum – способе организации рабочего процесса. Автор Agile Manifesto.


[Закрыть]столкнулся с невыполнимой задачей. Компании Easel Corporation, занимавшаяся разработкой программного обеспечения, предстояло менее чем за шесть месяцев создать новый продукт, призванный заменить устаревшие предложения. Сазерленд уже имел большой опыт в таких методологиях, как быстрая разработка приложений, объектно-ориентированное проектирование, циклы PDSA и работа с автономными исследовательскими группами skunkworks. Он захотел прямо в штаб-квартире корпорации Easel создать культуру, сочетающую преимущества как автономности, так и интеграции. И начал с того, что прочел все, что смог найти о повышении производительности организации. Изучив огромное количество материалов и переговорив с ведущими специалистами по управлению продуктами, Сазерленд заинтересовался несколькими оригинальными идеями.

Одна из них упоминалась в статье Лаборатории Белла о работе команды Borland Quattro Pro. В ней говорилось, что короткие ежедневные встречи команды резко повышают производительность группы.^[3] Схожие советы мелькали и в других материалах. Но краеугольным камнем концепции Сазерленда стало открытие «регбийного подхода» Такеути и Нонаки, хотя он скорее касался производства, а не IT. Позаимствовав многое из ключевых идей и добавив конкретные операционные практики, Сазерленд создал новый способ разработки программного обеспечения; используя лексику регби, он назвал его Scrum (схватка в регби). Методы Scrum позволили ему завершить, казалось бы, невыполнимый проект вовремя, оставаясь в рамках бюджета и с меньшим количеством ошибок, чем в любом предыдущем релизе. Позднее Сазерленд сотрудничал со своим давним коллегой Кеном Швабером, документируя этот подход, и в 1995 году они впервые представили Scrum публике.

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

В 2001 году семнадцать разработчиков, называвших себя организационными анархистами, встретились в городке Сноуберд, штат Юта, чтобы обменяться идеями. Среди них был Сазерленд и другие сторонники Scrum. В группу также входили приверженцы конкурирующих подходов, включая экстремальное программирование (XP), Crystal, адаптивную разработку программного обеспечения (ASD), функциональную разработку (FDD) и метод разработки динамических систем (DSDM). Все эти методы были в совокупности известны как «легкие» фреймворки, поскольку они использовали меньшее количество простых правил, позволяющих быстрее адаптироваться к меняющимся условиям. Немногие из присутствовавших считали эту терминологию лестной.

Новое название

Несмотря на разногласия, участники встречи в конце концов согласовали новое название для движения: Agile. Слово было предложено одним из участников, который тогда читал книгу Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer Стивена Л. Голдмана, Роджера Н. Нагеля и Кеннета Прейса.^[4] В книге приведено сто примеров компаний, включая ABB, Federal Express, Boeing, Bose и Harley-Davidson, которые разрабатывали новые способы адаптации к нестабильным рынкам. Выбрав название, присутствующие договорились издать «призыв к оружию», который назвали Agile-манифестом разработки программного обеспечения (Manifesto for Agile Software Development). В нем были сформулированы четыре ключевые ценности, которые разделяли все участники встреч. Например, «работающие решения важнее исчерпывающей документации» или «готовность к изменениям важнее следования первоначальному плану». Позже на этой встрече и в течение следующих нескольких месяцев они разработали двенадцать операционных принципов, таких как «Наш наивысший приоритет – удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения» и «Простота – искусство не делать лишней работы – имеет важное значение».^[5] Начиная с 2001 года все системы разработки, согласующиеся с этими ценностями и принципами, стали считаться Agile-методами.

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

Использование Agile расширялось. В 2016 году один из авторов этой книги – Даррелл Ригби – вместе с Сазерлендом и Такеути написал для журнала Harvard Business Review статью под названием Embracing Agile.^[6] К тому времени, как сообщалось в статье, организация National Public Radio использовала Agile-методы для создания новых программ, John Deere – для разработки некоторых новых машин, а Saab – для производства реактивного самолета Gripen. Винодельня Mission Bell Winery в Калифорнии использовала Agile «повсюду, начиная с производства вина и заканчивая складированием и работой команды старшего руководства».^[7] Базирующаяся в Массачусетсе компания OpenView Venture Partners поощряла свои портфельные компании за внедрение Agile-методов. С тех пор Agile распространился еще дальше, и мы приведем немало примеров, доказывающих это. И хотя сложное генеалогическое древо Agile иногда вызывает страстные споры среди приверженцев метода, два факта очевидны. Во-первых, корни и сферы применения Agile уходят далеко за пределы его информационных технологий; они применимы ко многим частям организации. Во-вторых, Agile продолжит распространяться. Он был разработан, чтобы помочь людям вырваться из тисков застоя – а в этом сейчас больше всего нуждаются компании, такие как Irresistible Snacks, по всему миру. И в этом и есть смысл Agile – восстановить баланс между бюрократией и инновациями.

Как работают Agile-команды

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

Чтобы использовать такую возможность, организация формирует и наделяет полномочиями небольшую команду, обычно от трех до девяти человек, большинство из которых работают весь день. Команда многопрофильна, и ее члены обладают всеми навыками, необходимыми для выполнения поставленных задач. Команда сама управляет и несет ответственность за все аспекты работы. Старшие руководители лишь указывают членам команды, где внедрять инновации. Столкнувшись с большой сложной проблемой, команда разбивает ее на модули, разрабатывает решения для каждого из них с помощью быстрого создания прототипов и быстрой обратной связи, а после интегрирует их в единое целое. Члены команды больше ценят адаптацию к изменениям, чем следование плану. Они считают себя ответственными за конечные результаты (такие как рост, прибыльность и лояльность клиентов), а не за промежуточные (такие как строки кода или количество новых продуктов). Команды тесно сотрудничают с клиентами, как внешними, так и внутренними. В идеале ответственность за инновации ложится на людей, наиболее близких к клиентам. Это сокращает число уровней контроля и согласований, тем самым ускоряя работу и повышая мотивацию команд.

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

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

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

Участник группы, являющийся владельцем инициативы, в конечном счете несет ответственность за создание ценности продукта для клиентов (включая внутренних клиентов и будущих пользователей) и бизнеса. Как правило, это представитель бизнес-функции, которая занимается работой с командой и координацией действий с ключевыми заинтересованными сторонами: клиентами, высшими руководителями и бизнес-менеджерами. Владелец инициативы может использовать такие методы, как дизайн-мышление или краудсорсинг, чтобы создать полный перечень перспективных возможностей. Затем он постоянно и безжалостно ранжирует этот перечень в соответствии с последними оценками важности тех или иных действий для внутренних или внешних клиентов и компании. Он не указывает команде, кто и что должен делать и сколько времени займет выполнение задач. Члены команды сами создают простую дорожную карту и детально планируют только те виды деятельности, в которых не ожидается изменений. Они разбивают наиболее приоритетные задачи на небольшие модули, решают, какой объем работы они возьмут на себя и как будут ее выполнять. Кроме того, участники четко определяют понятие «выполнено», а затем начинают создавать рабочие версии продукта в рамках спринтов. Процессом руководит фасилитатор (часто это обученный 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.