MegaFund – одна из крупнейших в мире компаний по управлению фондами: ее инновационные фонды привлекали инвесторов сильнее, чем фонды других организаций. Однако к 1997 году eTrade, Charles Schwab и другие финансовые компании произвели революцию в торговле акциями: у клиентов появилась возможность управлять своими счетами, покупать и продавать акции без участия и помощи профессиональных биржевых брокеров.

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

Специалисты компании изучили новые технологии и начали проект, который позволил бы получить доступ к старым базам данных, где хранилась вся информация о счете клиента и торговых операциях. После нескольких провальных запусков руководство MegaFund решило сделать все правильно. Обычно, когда менеджеры говорят, что собираются «сделать проект правильно», этот проект постепенно умирает от микрокоординации и избыточного администрирования. С этим проектом случилось то же: через девять месяцев он застопорился на неугасающих спорах о том, какие технологии использовать. Операционной системой должна быть Microsoft Windows NT 4.0, Solaris или AIX? Должна ли MegaFund стандартизировать технологию Intel? Какие серверы более масштабируемы: Sun или IBM? Использовать технологию COM или CORBA? Споры внутри организации продолжались, а конкуренты шли вперед.

Чтобы сдвинуться с мертвой точки и заставить проект двигаться, MegaFund решил применить скрам. Менеджер проекта Терри Адамс обладал хорошей технической экспертизой и интуитивным пониманием своей новой роли скрам-мастера: во время ежедневного скрама он внимательно слушал каждого участника команды. Когда возникала проблема с оборудованием, Терри протягивал руку помощи. Когда не хватало знаний и навыков, он помогал получить помощь извне. Когда не проходили заказы на покупку, Терри помогал их ускорить. Он умел устранять препятствия, не нарываясь на неприятности и не ставя свою работу под угрозу.

Команда разработки начала месячный спринт и в течение первых двух недель добилась впечатляющего прогресса: выбрала необходимые ей технологии, настроила инструменты и стала осуществлять первые транзакции. Целью спринта была выработка подхода к решению технологических проблем MegaFund и созданию пакета конкурентоспособных решений.

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

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

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

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

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

Рассел подумал об этом пару секунд и понял, что не хочет отменять спринт, иначе все узнали бы, что он остановил работу команды ради второстепенного требования. Планирование спринта явно указало бы на второстепенность задачи, а коллеги Рассела спросили бы, почему интересы его проекта важнее, чем их потребности. Расс поблагодарил Терри и добавил, что обязательно встретится с владельцем продукта, чтобы добавить свои требования в бэклог и договориться об их реализации в следующем спринте. Конечно же, он этого так и не сделал.

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

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