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

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

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

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

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

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

В ходе внедрения скрама в организации периодически случаются озарения, когда люди произносят: «Ах, вот оно как! Теперь я понял». Одно из первых озарений – когда команда разработки понимает, что она сама управляет собой. Первый проблеск появляется во время планирования спринта. Команда выбрала элементы бэклога продукта для следующего спринта, и что дальше? Повисает тишина, команда ждет, пока кто-то скажет ей, что делать. Ощущение дискомфорта нарастет: все ждут кого-то, кто расскажет о работе в команде. На этом этапе я напоминаю команде разработки, что спринт начался, до обзора осталось на два часа меньше, никто не собирается указывать и команда должна самостоятельно прояснить свою работу. Через несколько минут один из участников команды говорит: «Почему бы нам не разобраться, как должны выглядеть портлеты?» Еще один участник добавляет: «Есть ли у нас какие-то стандарты для внешнего вида портлета?»

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

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

В этой главе мы рассмотрим организацию Service1st, пережившую этот трудный переход. Рассмотрим команды, которые пытаются научиться самоорганизации и самоуправлению. Увидим, насколько тяжело скрам-мастерам и их командам начать самоорганизовываться и управлять собой, потому что это легко понять умом, но трудно реализовать. Эти подходы противоречат культуре многих компаний, и многие команды сбиваются с пути. Затем мы рассмотрим, как в компании WebNewSite я захожу сверху через руководство, чтобы вы могли поразмышлять о том, что представляют собой разумное и необоснованное лидерство скрам-мастера.

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

В подразделении разработки работало около 120 человек. Service1st использовала последовательный, или водопадный, жизненный цикл проекта, и персонал был организован соответствующим образом: дизайнеры подчинялись и отчитывались менеджеру по дизайну, программисты – менеджеру по программированию, тестировщики – менеджеру по обеспечению качества, технические писатели – менеджеру по документации. Service1st выпускала новую версию своего программного обеспечения примерно каждые шесть месяцев. Когда я пришел в компанию для внедрения скрама, следующий запланированный релиз включал агрессивную интеграцию программного обеспечения в основную линейку продуктов компании. Это ПО для совместной работы и бизнес-процессов создал новый партнер Service1st.