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