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

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

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

Извлеченные уроки

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

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

Проекты Service1st, Tree и Lapsec были настолько комплексными, что обычные методы планирования и управления не работали – проекты требовали тесной синхронизации многих видов деятельности. Во всех одновременно трудились несколько команд разработки, которые за короткий промежуток времени должны были создать готовый к демонстрации продукт. И все топтались на месте, пытаясь выяснить, с чего следует начать, как изменить свои ситуации и создать работоспособные планы.

Готовый скрам «из коробки» не содержит подходов, учитывающих комплексность любого взятого проекта. Тем не менее скрам-мастерам достаточно обратиться к теории скрама, чтобы найти методы, которые можно легко адаптировать для применения в проектах любой комплексности.

Таким подходом для всех трех проектов в Service1st, Tree и Lapsec была самоорганизация. Выступая в роли тренера или наставника, я учил команды применять практики скрама, включая самоорганизацию, чтобы справляться с возрастающим уровнем комплексности. Так мы понижали уровень сложности до степени, при которой команды разработки могли функционировать самостоятельно.

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

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

В засекреченном проекте Lapsec я должен был помочь команде начать применять скрам. Лекция по теории и практике скрама оказалась не очень полезной. Без упражнения с настоящими задачами и проблемами команда вряд ли поняла бы суть скрама. Показав участникам учебный пример, похожий на их реальную работу, я пробился к команде и помог ей прочувствовать, как применять скрам. Попав в рамки спринта, ограниченного максимум одним месяцем, участники команды разработки атаковали свою реальную проблему, словно стая диких собак, – ограничение во времени превосходно сработало. Марк Твен однажды сказал об этом: «Ничто не фокусирует ум так, как петля». Упражнение было той самой петлей фокусировки.

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

Чтобы заказчики могли выражать свои потребности напрямую владельцу продукта и команде разработки, скрам-мастер устраняет возникающие между ними препятствия, а также несет ответственность за объяснение владельцу продукта, как использовать скрам для максимизации рентабельности инвестиций (ROI) и соответствия целям проекта.

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

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