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