Текст книги "Коучинг agile-команд. Руководство для scrum-мастеров, agile-коучей и руководителей проектов в переходный период"

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

В этом случае вы нарушаете правило коучинга, в частности о том, что клиент – сам эксперт в собственной жизни. Не стесняйтесь поделиться опытом об Agile (в конце концов, вы его agile-наставник), но не учите его тому, как он должен жить. Только он знает это.

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

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

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

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

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

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

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

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

Это может поставить коуча в затруднительное положение.

Чтобы упростить ситуацию, постарайтесь завоевать уважение и используйте его в переговорах с владельцем продукта независимо от его положения. Как «бульдозер», «пастух», лидер-слуга и «страж» качества и эффективности вы должны учитывать все, что влияет на способность команды поставлять продукт и непрерывно совершенствоваться. Полностью освоившись с ролью agile-коуча, фокусируйте внимание на улучшении команды, делая это настолько прозрачно, чтобы было понятно: все разговоры между коучем и владельцем продукта направлены только на благо команды. Такая определенность поможет вам в завоевании авторитета. Используйте это.

СМОТРИТЕ ТАКЖЕ

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

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

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

КОУЧИНГ ВЛАДЕЛЬЦЕВ ПРОДУКТА В ВЕДЕНИИ БИЗНЕСА

Правила Agile учат нас, что во главе всего стоит поставка бизнес-ценности. Она расценивается как единственный критерий прогресса и стоимости. Мы просим владельцев продукта сортировать продуктовый бэклог на основе бизнес-ценности и чтобы никакие другие факторы не влияли на принятие решения. Итак, что же такое бизнес-ценность?

Этот важнейший вопрос требует более глубокого рассмотрения, чем доходность капиталовложений (ROI) или объем прибыли. Да, один или оба этих показателя – это часть уравнения, определяющего бизнес-ценность, но к ним присоединяются и другие, нечисловые факторы, такие как риск и приобретенные знания (Кон, 2006).

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

Это цели нижнего, основного уровня, и они определяют, на что владелец продукта нацеливает команду спринт за спринтом.

Микроопределения бизнес-ценности

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

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

Каждое решение владельца продукта проходит через фильтр микроопределения: наращивается ли количество пользователей [то, чего мы хотим] или мы получаем готовые партнерские каналы?

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

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

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

«ДЕЛАТЬ ПОНЧИКИ НА СТОЯНКЕ»

Agile-эксперт Рич Шеридан рассказывает эту историю, чтобы объяснить, какая невероятная мощь имеется в распоряжении владельца продукта для работы с командой (Шеридан, 2010).

Люди, приходящие в компанию Menlo Innovations или участвующие в наших мастер-классах, восхищаются простой игрой, посвященной планированию. Когда мы впервые ввели планирование в игровой форме в моей прежней компании Interface Systems, мой CEO Боб Неро был в восторге. Ему нравилось то, как мы занимаемся планированием и пересмотром нашего плана каждые две недели. Он воочию увидел уровень продуктивного взаимодействия между бизнесом и командами, разрабатывающими технологии, о которых прежде мог только мечтать.

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

– Рич, я серьезно озабочен той системой, которую вы создали. Она слишком гибкая.

– Что ты имеешь в виду, Боб? – спросил я.

– Рич, каждые две недели мы собираемся вместе, – ответил он, – чтобы заниматься планированием, компонуем истории, над которыми хотим работать, и точно следуем этому плану.

– Да, все верно, – подтвердил я.

– Через две недели мы можем вернуться к плану и полностью изменить его, и вы снова будете следовать ему, – сказал он.

Я заверил его, что так и будет.

– Но, Рич, – сказал он, – мы могли бы использовать этот инструмент для планирования чего-то другого, например для производства пончиков на парковке, и наша команда действовала бы таким же образом.

Я понял, к чему клонит Боб.

Я постарался ответить ему как коуч, используя метафору:

– Боб, представь, как сегодня вечером ты едешь домой на своем «лексусе». Осознаешь ли ты, что в твоих руках руль и ты можешь выбирать, куда повернуть – вправо или влево? Сделав неверный выбор, ты способен угробить автомобиль, убить себя и, возможно, еще несколько человек.

Он ответил:

– Да, но я бы никогда этого не сделал!

Я сказал:

– Точно! Поэтому не нужно поступать так с процессом. Он требует ответственного водителя за рулем. Если необходимы кардинальные изменения в бизнесе, то мы будем резко поворачивать руль. Но если нужно лишь небольшое маневрирование, то следует обсуждать это ежедневно.

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

Простые инструменты могут обеспечить отличный результат.

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

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

Игровая система бизнес-ценности

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

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

• владелец продукта обещал кому-то поставить особую функцию и попадет в неловкое положение, если откажется от своих слов;

• критерии оценки личной эффективности владельца продукта;

• функции, которые владелец продукта посчитал нужным добавить в бэклог;

• внешние группы, «готовые» сотрудничать с командой;

• внешние группы, которые сопротивляются работе с командой;

• «жесткие» зависимости, которые воспринимаются владельцем продукта как нерушимые.

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

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

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

Второй способ дает возможность владельцу продукта последовательно допустить каждое из препятствий. Для этого пригласите команду присоединиться. Вместе они могут обнаружить, что некоторые препятствия – это действительно сложные технические зависимости и их нельзя «отодвинуть». Если это так, то, возможно, история, имеющая более низкий приоритет, должна быть сделана прежде, чем высокоприоритетная. Что-либо другое может попасть в категорию «Мы хотели бы помочь, но…». Это сигнал: значит, компания ценит продукт недостаточно высоко, чтобы устранить препятствия, или издержки устранения превышают выгоду. В любом случае не забывайте об этом. Принимайте решения прозрачно, влияйте на команду так, чтобы она об этом знала. Если правда заключается в том, что компания позволяет команде работать вполсилы и поставлять меньше ценности, чем та в состоянии, то пусть все об этом знают.

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

КОУЧИНГ ВЛАДЕЛЬЦА ПРОДУКТА, НАЦЕЛЕННЫЙ НА ТО, ЧТОБЫ ОН РАЗДЕЛЯЛ ИНТЕРЕСЫ КОМАНДЫ

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

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

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

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

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

Целый ряд проблем в команде, как правило, можно исправить путем обучения (или переобучения) соответствующих работников ролям agile-коуча и владельца продукта. Попросите команду помогать исполнять свои роли коучу и владельцу продукта и добивайтесь, чтобы это стало нормой. Рассматривайте все что угодно, чтобы уменьшить препятствия выполнению работы.

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

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

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

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

КОУЧИНГ ВЛАДЕЛЬЦА ПРОДУКТА, НАЦЕЛЕННЫЙ НА ТО, ЧТОБЫ ОН ХОРОШО ВЫПОЛНЯЛ СВОЮ РОЛЬ

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

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

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

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

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

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

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

• Просите больше (или меньше), но не занимайтесь микроменеджментом: позвольте будильнику в вашей голове замолчать, когда владелец продукта думает, что ему нужно вникать в подробности того, как команда выполняет работу. Такое часто случается, когда владелец продукта считает, что команда выполняет недостаточный объем работы. Лучший контроль со стороны владельца продукта возможен тогда, когда он задает вопрос «Сколько команда готова сделать?» вместо «Как она это делает?». Научите его использовать это как уровень подготовки задач продуктового бэклога для следующего спринта. Настаивайте, чтобы он не вникал в детали.

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

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

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