Правильный Scrum: Эпизод 1 - Product Owner

Я больше 6 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

[sendpulse-form id=”278″]

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».

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

Для начала определимся, что же такое «механический scrum». С моей точки зрения, это когда формально присутствуют все роли, события и артефакты scrum, но забыты ценности и цели; когда отсутствует agile культура (т.е. высокая степень осознания и принятия agile manifesto и принципов). Когда нет понимания или даже попытки разобраться, для чего нужен тот или иной артефакт, или какая цель у событий в scrum. Все равно что робот в видео, который умеет крутить сальто, но кто назовет его гимнастом? При внедрении scrum важно донести до команды его цели и ценности, а не только механики. Agile культура усиливает scrum и делает его «настоящим». Scrum полезен для того, чтобы регулярно поставлять ценность и получать оперативную обратную связь. Scrum — это про скорость и развитие продукта. В теории звучит банально? Давайте попробуем разобраться, как работать по scrum и не растерять по дороге agile культуру и ценности scrum.

При разборе элементов scrum в ScrumGuide одними из первых разбираются роли, поступим так же. Т.к. материала много, то, чтобы дать возможность его осознать, он разбит на три эпизода. В первом проанализизуем роль Product Owner.

Product Owner — Владелец продукта (PO)

Product owner — это человек, отвечающий за продукт, он «владеет» продуктовым бэклогом. Главный инструмент PO — это видение развития продукта, а основная задача – максимизировать ценность продукта, выпускаемого командой. Вроде бы все просто: «Если ты смелый, ловкий и умелый…», но есть нюансы. У нас не учат на PO, зато учат на PM (project manager), и часто PM становятся PO, считая, что это просто смена названия, а подходы к работе можно оставить и старые. Но в agile так не работает. А как надо?

Взаимодействие PO и продукта, Backlog-а

Признак правильного SCRUM #1 – PO отвечает за Backlog и контролирует его

Симптом неправильности: PO просто работает над историями, полученными от других участников процесса. Или PO не отвечает за приоритезацию элементов backlog. Его работа доводить backlog до принятого в команде стандарта, а наполнение и приоритеты того, чем будет заниматься команда, он не определяет.
Чем плохо: Если PO не обладает смелостью или возможностью создавать продукт (формировать backlog, расставлять приоритеты, проводить эксперименты и т.д.), это не PO, а какой-то другой вид деятельности. А без PO scrum не scrum. Не формируя Backlog, PO не может отвечать за продукт. Если за backlog отвечает не PO, то принятие продуктовых решений требует дополнительных коммуникаций — это лишнее потраченное время, что негативно влияет на скорость команды.
Как лечим: нужно наделить PO единоличным правом принятия продуктовых решений и ответственностью за состав backlog. Если не принимающий решения PO — это установившийся порядок, то сложно в одночасье изменить ситуацию. Когда PO — это «proxy», то

• Либо убираем его из уравнения и делаем PO реально того, кто отвечает за состав и приоритизацию backlog. Помогать PO работать над backlog-ом могут как команда разработки, так и специальная исследовательская команда (Product Discovery Team), но ответственность за состав и качество backlog должна оставаться только за одним человеком — PO.
• Либо постепенно учим / позволяем / заставляем брать ответственность и принимать решения (состав элементов бэклога, приоритетность элементов и т.д.) текущего PO. Важны итерации: закрепление успехов, получение обратной связи.

Признак правильного SCRUM #2 – PO имеет четкую стратегию

Симптом неправильности: У PO нет видения развития продукта, у него нет глобальной стратегии, нет цели, куда нужно привести продукт и зачем.
Чем плохо: Главная сила PO — это видение продукта, понимание, для чего и для кого он создаётся. Этим видением он может мотивировать и «заражать» людей вокруг. Если видения нет, вряд ли продукт получится нужным и хорошим. Команда не будет «заряжена» на результат.
Как лечим: PO важно в первую очередь сформулировать видение продукта. Он должен уметь в формате elevator pitch рассказать, какую крутую штуку он делает, для чего и для кого. Одна из agile ценностей — это прозрачность. Визуализируя различные артефакты разработки продукта, мы работаем над прозрачностью. PO может сформулировать своё видение и вывесить его перед командой. Лучше если работа по формулировке elevator pitch и видения будет делаться с некоторой периодичностью — как и другие scrum события (запланировали новую итерацию — сделали — собрали обратную связь).

Признак правильного SCRUM #3 – PO постоянно работает над Backlog

Симптом неправильности: PO не прорабатывает элементы backlog, не доводит их до принятых в команде соглашений, не занимается актуализацией элементов backlog, не вычищает его, не делает backlog grooming.
Чем плохо: Если PO на текущий момент не уделяет достаточно внимания backlog на регулярной основе, ему все равно придется этим заниматься (спринты же надо собирать), но это будет более стрессово и затратно (например: коллективное наведение порядка в backlog на планировании спринта). Коммуникационные накладные расходы будут компенсироваться из времени, отведенного на разработку. PO начнет терять доверие команды: он не вкладывается в backlog – команда не будет вкладываться в инкремент. Плохой / неактуальный backlog уменьшает прозрачность для всех заинтересованных лиц. А scrum без прозрачности — не scrum.
Как лечим: До PO нужно донести важность работы над backlog — статьи, книги, тренинги и т.д. Нужно выработать правила / регламент проведения Product Backlog Refinement (PBR), чтобы эти встречи были полезными и эффективными, проводя мини-ретроспективу после PBR, за несколько итераций можно качественно улучшить это мероприятие. Нужно командно совершенствовать механизм проведения PBR, достигая максимальной синергии PO и команды разработки. Backlog нуждается в регулярной чистке. Получая свежую информацию помимо добавления свежих историй в backlog, нужно не забывать убирать истории, потерявшие актуальность. Backlog должен содержать понятные команде и проработанные (в рамках договоренностей конкретной команды) элементы на 2-3 спринта, глубже проработанный бэклог может потерять актуальность. В целом, бэклог должен содержать Roadmap хотя бы на год, чтобы все заинтересованные лица чувствовали, что у продукта есть будущее. Если держать backlog, побитый на примерные инкременты, это поможет команде заранее думать про цели спринта (sprint goals).

Признак правильного SCRUM #4 – PO играет только свою роль (и работает над одним или связанными между собой продуктами)

Симптом неправильности: PO работает над несколькими несвязанными продуктами или с несколькими командами. Или – помимо роли PO он занимает и другую роль в scrum процессе (или разработчик, или SM).
Чем плохо: Быть PO – это непростая работа, требующая большой отдачи. Если роль PO совмещается с другой деятельностью, то с большой долей вероятности это плохо повлияет на качество результата. Опытные и зрелые PO могут одновременно вести несколько продуктов и работать с несколькими командами, если эти продукты «родственные» или являются близкими по функционалу частями одного большого продукта. Скорее всего только очень и очень уникальные люди могут одновременно делать, скажем, графический редактор для мобильных устройств и армейский авиатренажер. Чтобы быть эффективным, необходимо держать фокус на одной цели, прежде чем жонглировать несколькими.
Как лечим: PO должен критично посмотреть на свои продукты: насколько проработано и сформулировано видение? Насколько команды понимают и принимают это видение? Насколько качественно проработан backlog? Прозрачен ли он для всех заинтересованных лиц? Есть ли roadmap продукта, всем ли он понятен? Команда понимает, чем будет заниматься ближайшие 2-3 спринта? Насколько хорошо известен пользователь и рынок? Какое качество взаимодействия с командой разработки? Если в каких-то из этих вопросов есть место для качественных улучшений, стоит оставить себе один продукт и сфокусироваться на нем.

Взаимодействие PO и команды

Признак правильного SCRUM #5 – PO не работает как PM и позволяет принимать команде решения не влияющие на стратегию самостоятельно

Симптом неправильности: PO директивно управляет командой, фактически работая по классической PM схеме. PO принимает все решения, даже самые незначительные, команда бегает к нему по любому вопросу.
Чем плохо: Если PO занимается микроменеджментом внутри команды, принимает активное участие в разработке, то, с одной стороны, это демотивирует команду и не даёт ей развиваться (нет самоорганизации, ведь ответственность за локальные решения остается на PO), с другой стороны, это плохо для продукта, потому что усилия PO направлены внутрь процесса, и продукт может оставаться без его внимания.
Как лечим: PO нужно убивать в себе PM, пробовать недирективные подходы в управлении и перестать воспринимать людей как ресурс. Если выстраивается директивная схема управления между PO и командой разработки, стоит привлечь внешнего или внутреннего фасилитатора, способного скорректировать взаимодействие. Нужно четко обозначить границы ответственности между PO и командой разработки — это прозрачность. Между PO и командой должны быть доверительные отношения: команда по большей части доверяет PO и его продуктовым решениям, а PO доверяет команде и тем решениям, которые команда принимает для реализации элементов backlog. У всех есть понимание того, что работа ведется для единой цели. Одним из возможных инструментов для PO может стать его «продуктовая» команда, в составе которой есть аналитики. Когда гипотезы основаны на цифрах и данных, то они вызывают больше доверия. Главное для PO не забывать делиться этими данными с командой разработки. Если команда несамостоятельная, то PO нужно учиться делегировать. Тогда команда будет вынуждена брать на себя принятие решений, как следствие ответственность, и постепенно она станет scrum командной.

Признак правильного SCRUM #6 – PO не конфликтует с командой, между ними есть понимание

Симптом неправильности: PO и команда разработки регулярно конфликтуют, идет постоянная конфронтация, нет взаимопонимания.
Чем плохо: PO и команда плывут в одной лодке, если между ними не налажены эффективные коммуникации, то вряд ли такая лодка сможет далеко уплыть. Много энергии будет тратится на налаживание взаимодействия, а не на разработку продукта. Цель у PO и команды одна и та же, значит, регулярных конфликтов быть не должно.
Как лечим: Нужен опытный фасилитатор, способный выявить суть конфликта, убрать его и выстроить рабочие отношения. Если же все усилия не приводят к взаимопониманию, то возможно стоит поменять тандемы.

Признак правильного SCRUM #7 – PO постоянно коммуницирует с командой, но не отвлекает ее

Симптом неправильности: PO почти не коммуницирует с командой. Например, он доступен только в рамках обязательных встреч (планирование, sprint review).
Чем плохо: Команда создает новый сложный продукт (Scrum is a framework for developing, delivering, and sustaining complex products.), следовательно работает в условиях большой неопределенности. Чтобы доставлять максимальную ценность им нужна информация, которая в большинстве случаев есть только у PO (это же его работа). При отсутствии информации могут делаться неправильные предположения и решения, как следствие будет теряться драгоценное время на их исправления.
Как решать: PO должен быть доступен для команды, но команде не стоит этим злоупотреблять, иначе время PO будет расходоваться только на ad hoc вопросы. Следует выработать комфортный для всех формат взаимодействия, при котором команда своевременно получает от PO необходимую информацию и решения, которые команда действительно не может принять самостоятельно. Можно с определенной регулярностью звать на ретроспективы PO и обсуждать там вопрос частоты, инструментов и формата коммуникаций.

Признак правильного SCRUM #8 – PO развивает и поощрает обратную связь от команды

Симптом неправильности: PO не прививает и не поощряет культуру обратной связи в команде. Или PO даёт однобокую обратную связь, отфильтровывая похвалу или критику.
Чем плохо: Когда PO не дает регулярную честную обратную связь команде, это демотивирует команду. Нет синхронизации по ожиданиям и результатам. Команда не чувствует соучастия, они фактически не являются создателями продукта, они просто выполняют свою функцию. «Команда регулярно поставляет инкремент. Команда регулярно получает честную обратную связь по своей работе» — кажется, это справедливая сделка.
Как лечим: PO конечно же не должен взваливать на команду весь тот объем информации с которым, он работает сам, все то, что он получает от пользователей и аналитиков. Он должен агрегировать и выдавать уже важную и понятную команде информацию. Хорошо придумывать различные форматы для обратной связи, а не только на базе сухих цифр (например: живые тестирования, интервью и т.п.). Команда сама должна напоминать PO о необходимости обратной связи: задавать вопросы, выстраивать регулярный процесс получения обратной связи. Если PO сделать «владельцем» события sprint review и озадачить его тем, что команда нуждается в обратной связи, это как минимум будет напоминать PO о работе над обратной связью, а может побудить к более творческому подходу в организации таковой.

Взаимодействие PO и пользователей, рынка

Признак правильного SCRUM #9 – PO знает целевую аудиторию своего продукта и общается с ней

Симптом неправильности: PO не знает «своего» пользователя; продукт видит, как набор фич. PO игнорирует пользовательские запросы и информацию от существующих пользователей. Не общается с «живыми» пользователями.
Чем плохо: В первую очередь, продукт создаётся для пользователя, у которого есть (возможно, он этого пока не знает) потребность, удовлетворяемая продуктом. И если не знать и не понимать пользователя, то невозможно «нести ответственность за достижение максимальной ценности продукта», как этого требует scrum guide.
Как лечим: Есть много различных инструментов для проведения качественных исследований, например глубинные интервью, портрет пользователя, «дорожная карта» пользователя (customer journey map), инструменты для сбора качественной (vs количественной) аналитики и т.д. и т.п. Нужно пробовать различные инструменты и оставлять полезные / работающие для вашего продукта. Большинство этих инструментов на выходе имеют визуализацию результата, стоит их размещать перед командой, чтобы увеличивать прозрачность. Эти артефакты стоит время от времени актуализировать. Можно организовать исследовательскую команду (product discovery team) для помощи в проведении качественных исследований. Если PO сумеет наладить взаимодействие с пользователем, то он может этот контакт использовать, например, на sprint review: давая пользователю свежий инкремент, а команда будет исследовать, как пользователь справится с задачей, помощь в решении которой они закладывали в инкремент.

Признак правильного SCRUM #10 – PO знает рынок и конкурентов

Симптом неправильности: PO не изучает рынок / конкурентов.
Чем плохо: Продукт живет как будто в вакууме, и оторван от реальности, нужно быть провидцем, чтобы создавать ценный продукт в таких условиях.
Как лечим: Есть ряд практик для владельцев продуктов, как изучать и создавать рынки, стоит пробовать различные из них и оставлять приносящие пользу. В этой деятельности PO могут помогать аналитики или команда. Полезно время от времени искать “голубые океаны“. Ну и конечно же, стоит черпать вдохновения на тренингах, продуктовых митапах и конференциях.

Заключение

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

1. Читая почти каждый из пунктов, вы узнавали себя (свою команду / организацию), т.е. у вас scrum с неканоническим пониманием. Тогда стоит задаться вопросами: нужен ли вообще вам scrum? Для чего вам scrum? Какие перед ним вы ставите задачи? Корпоративная культура готова к ценностям и принципам agile? Если у вас есть ответы и понимание, для чего нужен scrum, и вы действительно делаете на него ставку, то переходите ко второму варианту. Если нет, то перестаньте заниматься самообманом.
2. Читая некоторые пункты вы подумали, что это не про вас. Некоторые пункты натолкнули вас на рассуждения и вы вспомнили свою ситуацию. Если это так, то выберите те пункты, которые могут быть применимы к вашей ситуации. Распечатайте их в виде карточек. Обсудите с командой симптомы: справедливы ли они для вас? Обсудите риски, согласны вы с ними, или, может быть, вы видите более опасные последствия от симптомов. Затем возьмите карточку, которая больше всего волнует команду, самый опасный симптом в настоящий момент. Рассмотрите предложенный вариант решения, подходит ли он вам? Придумайте коллективно, как можно улучшить ситуацию, как снять симптом. И действуйте! Разобравшись с одним симптомом, переходите к следующему, периодически возвращаясь к общему обзору, чтобы быть уверенными, что не просели уже достигнутые вами результаты.
3. Если вы прочитали все и не узнали в этих ситуациях свои реалии, у вас все правильно. Вы большие молодцы!

P.S. Надеюсь, что эта серия статей даст рабочий инструмент scrum командам для самосовершенствования.