Книга: Скрам
Назад: Волк в MegaFund
Дальше: Глава 4 Команда разработки. Создаем порядок из хаоса

Выводы

В Trey Research и Litware мы увидели, как нелегко бывает понять роль скрам-мастера, в  – как скрам-мастер может нарваться на увольнение, а в MegaFund – как скрам-мастер одновременно и выполняет обязанности новой роли, и внедряет правила и практики скрама в организации. В каждой компании произошло что-то уникальное. Зная о практиках и правилах скрама, скрам-мастера по-разному реагировали на ситуации: в одних случаях реакция была подходящей для организации, в других – нет. В каждом случае скрам-мастер интерпретировал свои обязанности и цели по-своему, поэтому и результаты значительно отличались.
Последние несколько лет я ломал голову над вопросом: как наиболее понятно продемонстрировать разницу между менеджером проекта и скрам-мастером, между коучем и боссом? Как доступно объяснить сдвиг между этими ролями любому человеку, независимо от опыта и предубеждений? Мой вывод – новых скрам-мастеров должны тренировать опытные практикующие коллеги. Переход к новой роли в таком случае обычно проходит гладко. Например, когда сопровождаю новых скрам-мастеров, я могу помочь им понять многие последствия неправильного применения скрама, потому что сам совершал подобные ошибки не раз. Еще я могу показать им разницу между провалом и успехом.
Обычно я тренирую новых скрам-мастеров следующим образом. Сначала я начинаю выполнять роль скрам-мастера сам, чтобы дать пример поведения новому скрам-мастеру. Затем мы меняемся ролями, и новичок приступает к работе. После каждой встречи и в течение дня я комментирую произошедшие ситуации и объясняю, что получилось хорошо, а что можно было сделать по-другому. Указываю на моменты, когда скрам-мастер мог помочь команде разработки. Подсказываю, что он мог и может сказать. Указываю на случаи, когда скрам-мастер контролировал, а не направлял, и поясняю возможные последствия такого поведения.
Скрам-мастер несет ответственность за то, чтобы все части процесса скрама, соединяясь, работали вместе. Владелец продукта должен хорошо выполнять свою работу. Команда разработки должна хорошо выполнять свою работу. Цыплята должны вставать в очередь, чтобы добавить свои пожелания в бэклог. Владелец продукта и команда разработки должны надлежащим образом сотрудничать и проводить события скрама для инспекции и адаптации.
Обязанности скрам-мастера можно резюмировать следующим образом:
■ устранять барьеры между командой разработки и владельцем продукта, чтобы владелец продукта напрямую общался с участниками команды и направлял разработку;
■ научить владельца продукта максимизировать рентабельность инвестиций (ROI) и достигать своих целей с помощью скрама;
■ улучшать жизнь команды разработки: поощрять креативность и расширять полномочия участников по выбору способов реализации требований из бэклога продукта;
■ повышать производительность команды разработки любыми способами;
■ улучшать инженерные практики и инструменты, чтобы каждый инкремент продукта был готов к поставке;
■ поддерживать информацию о прогрессе команды актуальной и доступной для всех.
Когда скрам-мастер выполняет эти обязанности, прогресс проекта обычно стабилен, а цель спринта достигается. Этих обязанностей достаточно, чтобы скрам-мастер был занят и у него не оставалось времени на поведение типичного босса. Обратное тоже верно: скрам-мастер, который ведет себя как менеджер проекта, скорее всего, не выполняет все свои обязанности скрам-мастера.
По моему опыту, некоторые люди интуитивно понимают роль скрам-мастера и ощущают себя в ней словно рыба в воде. Другим это понимание дается с трудом; обучаясь, они совершают неприятные ошибки. Но даже успешному скрам-мастеру требуется несколько спринтов, чтобы влиться в работу.
Когда я не знаю, чем могу помочь, я повторяю в уме фразу: «Скрам – искусство возможностей». Вместо того чтобы расстраиваться тому, что не удается или нельзя сделать, сосредоточьтесь на том, что можно сделать сейчас. Эта установка помогает направлять мои действия как в проектной деятельности, так и в повседневной жизни.
Назад: Волк в MegaFund
Дальше: Глава 4 Команда разработки. Создаем порядок из хаоса