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

Используйте «сюхари», чтобы помочь команде понять ценности методологии

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

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

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

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