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

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

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

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

Все это известно коучу, потому что он понимает ценности и принципы Agile и Scrum и знает, как они управляют практиками, а также то, из-за чего эти методологии могут стать формальными. Scrum-коуч хорошо знаком с понятиями «коллективная ответственность» и «самоорганизация». ХР-коуч отлично понимает, что такое приветствие изменений и инкрементальная архитектура. Канбан-коуч знает, как улучшить командные процессы при помощи введения WIP-лимитов, и использует их для контроля рабочего потока – и когда кто-то пытается нарушить выставленные лимиты и включить в список как можно больше задач, то вся методология разваливается.

В своей книге Coaching Agile Teams Лисса Адкинс советует коучам, как правильно подходить к проблемам, связанным с командой. Об этом мы уже упоминали в , но стоит повторить.

Это превосходный совет для любого agile-коуча, особенно того, кто склонен к командно-административному стилю управления или считает необходимым контролировать каждый аспект обучения и прогресса команды. Хороший коуч понимает: есть моменты, когда команда может и должна потерпеть неудачу, потому что это самый действенный и эффективный путь к успеху.

Это тот случай, когда ретроспективы приобретают чрезвычайную ценность. Мы узнали о том, как scrum– и XP-команды используют ретроспективы, чтобы в ходе проекта провести ретроспективный анализ и найти пути для улучшения. Для agile-коуча это отличная возможность помочь команде извлечь урок из провала, именно для этого его и позволяют. Если команда ошибается, потому что недостаточно точно применяет практику, то коуч поможет понять, какие из текущих навыков требуют улучшения. Но иногда сбой происходит из-за устаревшего образа мыслей. Зная принципы работы методологий и практик, agile-коуч использует провал, чтобы помочь команде узнать больше о конкретной ценности или принципе. Благодаря этому она примет правильное решение и избежит неудачи. Благодаря этому команды прогрессируют.

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

В мы прочли о руководителе, который непреднамеренно «подрезает крылья» всем канбан-усилиям, когда просит команду убрать WIP-лимит. Кто-то с уровнем понимания «сю» может позволить изменить WIP-лимит, полагая, что сможет получить пользу, оставив хотя бы часть Канбана. Хороший канбан-коуч осознает, что некоторые вещи (например, конкретные столбцы на канбан-доске) могут быть изменены, но WIP-лимит должен оставаться без изменений, потому что это стержень, на котором держится методология Канбан.

Одна из наиболее трудных задач коуча – понять, какую именно информацию необходимо объяснить команде, какую – руководителю, а какую – клиентам. Разъяснения правил методологии на уровне «сю» достаточно, чтобы работа была выполнена, но мало, если нужно помочь команде получить правильное мышление и достичь результата «лучше-чем-ничего».

Иногда команде хватает элементарного набора правил, а порой она чувствует, что просто подменяет случайный набор правил каскадной модели столь же случайным набором agile-правил. Уровень «ха» помогает увидеть, почему следование этим правилам позволит создавать лучшее программное обеспечение. Но это также может звучать как «удручающий дзен», как выразился Кокберн. Agile-коуч нужен, чтобы помочь команде двигаться вперед на уровень понимания «ха» в таком темпе, при котором можно справляться с работой без чрезмерно абстрактных объяснений, которые ей не помогают.