Скрам - Кен Швабер

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

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

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

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

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

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

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

В Trey Research и Litware мы увидели, как нелегко бывает понять роль скрам-мастера, в Contoso.com – как скрам-мастер может нарваться на увольнение, а в MegaFund – как скрам-мастер одновременно и выполняет обязанности новой роли, и внедряет правила и практики скрама в организации. В каждой компании произошло что-то уникальное. Зная о практиках и правилах скрама, скрам-мастера по-разному реагировали на ситуации: в одних случаях реакция была подходящей для организации, в других – нет. В каждом случае скрам-мастер интерпретировал свои обязанности и цели по-своему, поэтому и результаты значительно отличались.

Последние несколько лет я ломал голову над вопросом: как наиболее понятно продемонстрировать разницу между менеджером проекта и скрам-мастером, между коучем и боссом? Как доступно объяснить сдвиг между этими ролями любому человеку, независимо от опыта и предубеждений? Мой вывод – новых скрам-мастеров должны тренировать опытные практикующие коллеги. Переход к новой роли в таком случае обычно проходит гладко. Например, когда сопровождаю новых скрам-мастеров, я могу помочь им понять многие последствия неправильного применения скрама, потому что сам совершал подобные ошибки не раз. Еще я могу показать им разницу между провалом и успехом.

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

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

Обязанности скрам-мастера можно резюмировать следующим образом:

■ устранять барьеры между командой разработки и владельцем продукта, чтобы владелец продукта напрямую общался с участниками команды и направлял разработку;

■ научить владельца продукта максимизировать рентабельность инвестиций (ROI) и достигать своих целей с помощью скрама;

■ улучшать жизнь команды разработки: поощрять креативность и расширять полномочия участников по выбору способов реализации требований из бэклога продукта;

■ повышать производительность команды разработки любыми способами;

■ улучшать инженерные практики и инструменты, чтобы каждый инкремент продукта был готов к поставке;

■ поддерживать информацию о прогрессе команды актуальной и доступной для всех.

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

По моему опыту, некоторые люди интуитивно понимают роль скрам-мастера и ощущают себя в ней словно рыба в воде. Другим это понимание дается с трудом; обучаясь, они совершают неприятные ошибки. Но даже успешному скрам-мастеру требуется несколько спринтов, чтобы влиться в работу.

Когда я не знаю, чем могу помочь, я повторяю в уме фразу: «Скрам – искусство возможностей». Вместо того чтобы расстраиваться тому, что не удается или нельзя сделать, сосредоточьтесь на том, что можно сделать сейчас. Эта установка помогает направлять мои действия как в проектной деятельности, так и в повседневной жизни.