Author

lomakova

Browsing

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

Проблема сложности перенимания экспертизы

Очень часто новый участник команды разработки имеет возможность перенять экспертизу у своих новых коллег, которые на ежедневной основе занимаются тем же, чем и он. У Скрам Мастера такой роскоши, как правило, нет. Он приходит в команду и оказывается там единственным носителем своей экспертизы. Зачастую бывает даже так, что команда ранее не работала со Скрам Мастером. Тогда задача синхронизироваться и начать продуктивную совместную работу сильно усложняется. На начальных этапах взаимодействия можно допустить ошибки и упустить важные детали из виду. На обмен знаниями в таких условиях рассчитывать не приходится.

Проблема неполноты картины 

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

Необходимость наладить контакт

Команды не всегда положительно настроены к новому Скрам Мастеру — у них бывает много сомнений, плюс они не всегда являются волонтерами. Это даже не основная проблема. Во взаимодействии может быть много острых углов: уровень самоорганизованности команды, корпоративная и внутрикомандная культура, внутренние конфликты и т. д. Скрам Мастер должен быть как лидером, так и другом. А это значит, что, выходя в новую команду, Скрам Мастеру необходимо в короткие сроки завоевать доверие и авторитет.

Скрам Мастер может столкнуться с сопротивлением и даже с саботажем

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

Распространенные ошибки Скрам Мастера

  1. Натягивание фреймворка

 Очень печальная история получается с начинающими Скрам Мастерами, когда они, имея представление лишь об одном фреймворке, пытаются протолкнуть его везде без понимания контекста. А потом в интернете появляются статьи с названиями «Скрам терроризм» или «Скрам не работает».

2. Попытка взять на себя всю ответственность

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

3. Игнорирование собственного выгорания

Выгоревший Скрам Мастер в лучшем случае бесполезен для команды, а в худшем — будет плохо на неё влиять. Как говорится, сначала наденьте кислородную маску на себя, а потом — на ребенка. В начале мы должны научиться сами находить баланс между работой и отдыхом, научиться пребывать в ресурсном состоянии и черпать вдохновение от своей работы.

4. Менять процесс без ведома заинтересованных лиц

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

5. «Так написано в Скрам Гайде»

Довольно типичная ошибка начинающего Скрам Мастера — это пытаться сделать все по книжке. Никогда не отвечайте команде на вопрос «Зачем мы это делаем?» фразой «Так написано в Скрам Гайде». Такой ответ лишь выдает неглубокое знание фреймворка и слепой фанатизм.

Поведенческие стратегии

В первую очередь нужно понять, что самая выгодная роль — это быть самим собой. Некоторая фальшь в поведении Скрам Мастера довольно быстро прочувствуется и распространится на остальных. Мы посвящаем довольно большую часть жизни работе. Готовы ли мы все это время притворяться кем-то кем мы не являемся? Нужно быть достаточно смелым, чтобы разрешить себе просто быть самим собой. Когда люди вокруг видят, что их принимают со всеми недостатками и особенностями, они понимают, что они на своем месте. Это приносит гармонию и взаимопонимание в коллектив, формирует доверие и уважение. И, как показывает практика, именно такая атмосфера помогает раскрыть в людях таланты.

Выстраиваем безопасную среду

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

Что делает Скрам Мастер? На своём опыте он может показать, что ошибаться — это нормально, что любой специалист может чего-то не знать. В таком случае, если возникнет какая-то проблема, она станет известна команде довольно быстро. Следовательно, приступить к её решению можно будет своевременно. 

Выявить уровень самоорганизации команды

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

Просить о помощи

Сделать всё самостоятельно — это не цель скрам мастера. Внутри команды усилия Скрам Мастера должны быть направлены на то, чтобы привести команду к самоорганизации. И здесь хорошо работает собственный пример. Логика такая: вы смело просите о помощи; команда понимает, что это никак не уменьшает вашу компетенцию; и это разрушает барьер, если таковой имеется. 

Выстраивать личные границы

Часто бывает так, что команда подшучивает над своим Скрам Мастером. И шутки могут быть разные — от вполне безобидных до тех, которые действительно могут задеть. А иногда шутки могут стать индикатором непонимания процессов. В таких случаях нужно уметь выстроить границы. Честно сказать, если вас шутки задевают. Или же проследите, что именно вызывает те или иные шутки. Например, команда часто говорит что-то вроде: «Наконец-то ретроспектива! Можно не работать!» Это может указывать на то, что пора менять формат ретро или искать способы сделать эту встречу более эффективной. Однако порой на некоторые шутки стоит отвечать ответными шутками или преувеличением. Иногда шутки являются неотъемлемой частью культуры команды. 

Связь со внешним миром

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

Минимальные действия

Есть всего 4 вещи, сделав которые, Скрам Мастер может избежать большинства проблем и опасностей в будущем.

  1. Выравняться в ожиданиях

Как правило у команды и Владельца Продукта есть конкретные проблемы, с которыми они рассчитывают обратиться к Скрам Мастеру. Проведите небольшую встречу, где вы выравняетесь в ожиданиях от вашей работы. После такой встречи и сбора проблем можно составить процессный Road Map и рассказать о нем команде. Так ваши действия и ваша работа будут максимально прозрачны для всех.

2. Объяснить свою роль и зону ответственности

Роль Скрам Мастера достаточно сложна для понимания. Поэтому хорошим тоном будет рассказать, как вы видите свою роль в команде. На конкретных примерах объясните, на какую помощь от вас команда может рассчитывать, что входит в вашу зону ответственность, а что нет.

3. Договориться об обратной связи

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

4. Разберитесь в контексте

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

Вхожение в контекст

Для Скрам Мастера очень важно понимать контекст, в котором находится его команда. Довольно часто мы обращаем внимание на внутреннюю кухню команды, но забываем о внешних факторах и рисках, влияющих на работу. Поэтому для лучшего понимания контекста мы выбрали классическое для менеджмента деление на внешнюю и внутреннюю среду.

Приведенные ниже блоки это области, на которые Скрам Мастеру стоит обратить внимание. Получив ответы на вопросы в этих блоках, Скрам Мастер может дать оценку ситуации в команде и составить для себя списк проблем, над которыми стоит работать.

Внутренняя среда

Команда
РолиКакие роли есть в Команде Разработки?
ВовлеченностьВсе ли в команде выделены на 100%?
ОпытКак довно люди работают в команде/организации?
Co-locationВсе ли находятся в одной локации?
Иерархия Формальная и неформальная иерархия в команде
ВакансииЕсть ли открытые вакнсии? Планируется ли еще набор?
Психологические аспектыКто лидеры в команде? Доминанты? Инноваторы? Консерваторы? Скептики? Кто эмоционально выгорает?
OnBoardingКак происходит обучение и адаптация новых сотрудников?
ИнформированиеКак сообщаются важные новости команде?
Регламенты команды
Командное соглашениеЕсть/нет
Definition of ReadyЕсть/нет
Definition of DoneЕсть/нет
Обучение в команде
Обратная связьЕсть/нет
Оценка задачЕсть/нет
Декомпозиция задачЕсть/нет
Процесс (фреймворк/метод)Есть/нет

Продукт/Бизнес область
Product OwnerКакими полномочиями обладает?
ВидениеЕсть/нет
Road MapЕсть/нет
Границы продуктаЕсть/нет
Стратегия Есть/нет
Product BacklogКак выглядит Product Backlog? Насколько он актуален ? Насколько он открыт для стейкхолдеров и команды?
ЦелиКакие цели/ KPI стоят перед командой?
Продуктовые метрикиЕсть/нет
БюджетКак бюджетируется команда?

Технологии
Инженерные практикиКакие инженерные практики команда применяет или пробовала применять?
Релизная политикаКак часто команда может выводить готовый функцианал в прод?
Зависимости от других командЕсть ли зависимости на техническом уровне от других команд?
Инцидент менеджментКак происходит работа с инцидентами? Чья это зона ответственности?
Технический долгЕсть ли у команды выделенное время для работы над тех. долгом? Как приоритизируются технические задачи?
Звездная карта/ T-shape картаЕсть/нет
АрхитектураС какими системами есть интеграции? Что будет если системы с которыми мы интегрируемся перестанут корректно работать?
Информационная безопасностьКто отвечает за ИБ? Как происходит коммуникация и в какой момент?
СтандартыЕсть ли у организации технологические стандарты. Кто отвечает за их внедрение?

Процесс
Визуализация процессаЕсть/нет
Процессные метрикиЕсть/нет
МероприятияКак проходят мероприятия в команде? Имеют ли они ценность для команды?

Внешняя среда

Ближняя внешняя среда
Роли влияющие на командуSWA? Центры экспертизы? Представители на уровне правления? CTO? HR? Вендоры?
Карта стейкхолдеровЕсть/нет
Карта зависимостейЕсть/нет

Следующие блоки нельзя назвать обязательными. В команде Владелец Продукта должен обладать знаниями в этих областях. Однако если Скрам Мастер будет напоминать Владельцу Продукта мониторить актуальную картину по этим вопросам, это может быть крайне полезно для команды.

Дальняя внешняя среда
Клиент/пользовательКто клиент/пользователь? Как собирается обратная связь?
РынокКакая ситуация на рынке?
КонкурентыКто основные конкуренты? Какие у них преимущества/недостатки?
ГосударствоКакие законопроекты могут повлиять на работу команды?

Авторы статьи: Ломакова Анастасия, Кочарян Эмилиа
Приняли участие в сборе информации: Федулова Светлана, Щербаков Никита, Соколов Кирилл, Кручинина Мария

Начиная с конца 2017 года Scrum.org стал акцентировать внимание на таком понятие, как ServentLeadership (Лидерство-служение)  для Скрам Мастеров. Ведь в конце концов Скрам гайд определил, что Скрам Мастер — это лидер-слуга как Скрам-команды, так и всей организации, в которой он работает.

Этот тип лидерства не является новым. По крайней мере, я слышал о нем каждую воскресную службу в церкви с пяти лет. Сам Роберт Гринлиф, который первым продвигал концепцию лидера-слуги в мире, был вдохновлен историями из Библии. Но, даже несмотря на давнее знакомство с этой концепцией, я понимаю, что будет довольно сложно объяснить ее на тренинге для Скрам Мастеров. Чтобы научить кого-то этому типу лидерства, вам в первую очередь нужно уметь самим быть лидером-слугой. Иначе люди получат от вас лишь теорию.  

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

Лидер-слуга не ставит себя на первое место

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

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

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

Лидер-слуга сосредотачивается на развитии других

Я встречал много людей, которые спрашивали меня «Если моя команда не справляется и не соответствует ожиданиям, не должен ли я наказать их?». Также многие спрашивали меня «Если есть член команды, работа которого не такая результативная, как у других, следует ли мне наказать этого человека?». Многие компании и лидеры зациклены на модели кнута и пряника, и придерживаются её долгие годы. К сожалению, такой стиль руководства больше не актуален для 21-го века, так как он не гуманен. Эпоха использования кнута и пряника для наказания неэффективных работников уже закончилась. Эта эпоха закончилась и нужно оставить ее в прошлом.

Традиционная модель наказания непродуктивных членов команды никогда не имела никакого смысла для меня лично. Это просто неправильно. Лидер-слуга должен помогать таким людям и способствовать тому, чтобы они стали успешнее. Лидер-слуга всегда старается помогать другим в развитии, а не наказывать, обвинять или судить их. Скрам Мастер должен спросить слабого члена команды «Что я могу сделать для тебя, чтобы ты мог стать успешнее и разобраться с этой ситуацией?». Ваша цель как лидера-слуги — это не ваше величие, а величие других людей. Возможно, вам придется пройти лишнюю милю или пожертвовать своими личными ресурсами, чтобы сделать этих людей успешнее.

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

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

Лидер слуга гуманен и уважает потребности других людей

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

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

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

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

Лидер-слуга имеет мужество говорить правду

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

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

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

Лидер-слуга — это другое. Он искренен, у него нет никаких скрытых мотивов и никакого личного интереса в работе. Сказанная правда улучшит людей и организацию, в которой он работает, поднимет на новую высоту, а не навредит им. Правда заставит людей думать по-другому, а не оставаться в статусе-кво или чувствовать себя в зоне комфорта Лидер-слуга создаёт среду, в которой люди могут чувствовать себя в безопасности, говоря правду.

Лидер-слуга может признать собственную уязвимость

Мы видели из предыдущих пунктов, что лидер-слуга фокусируется на служении другим для большего общественного блага. Лидер-слуга — это также лидер, который имеет смелость честно признаться в собственной уязвимости. У лидера-слуги есть смирение сказать, что у него нет ответов на все вопросы, и любой совет, который он дает, не является абсолютной истиной.

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

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

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

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

Оригинал: https://www.scrum.org/resources/blog/what-servant-leadership
Перевод: Ломакова Анастасия
Редакция: Кочарян Эмилиа, Карамнова Виктория

Definition of Ready (DoR) инструмент про который довольно сложно найти информацию в интернете. Строго говоря в Скрам Гайде нет такого термина или описания этого инструмента. Однако если обратиться к Scrum Glossary то можно найти такой термин как Ready.

Ready: a shared understanding by the Product Owner and the Developers regarding the preferred level of description of Product Backlog items introduced at Sprint Planning

Ready — это общее понимание/договоренность между Владельцем Продукта и Командой Разработки о предпочтительном уровне проработки элемента Бэклога Продукта к моменту планирования.

DoR должен быть своеобразным щитом для команды

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

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

Как работать с Definition of Ready

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

Говоря общими словами нам нужно критически посмотреть на каждый пункт DoD и задать себе вопрос: «Как он влияет на Time To Market?»

Для более полного понимание прикрепляю к этой статье Definition of Ready одной из моих команд.

Подробнее вы можете ознакомиться на примере.

Definition of Ready (DoR) пример

До PBR:

  • Impact/value задачи посчитан
  • Есть минимум один сценарий, описывающий успешную работу функционала

Во время PBR:

  • Задача сформулирована как User Story*
  • Сформулированы критерии приемки
  • Задача декомпозирована до уровня достаточного для оценки
  • У задачи есть оценка в Story Points
  • Есть согласованные макеты дизайна интерфейса*
  • Есть список стейкхолдеров, контактных лиц из других команд*
  • Согласованы сроки реализации и API с внешними командами*

    * Если применимо к задаче

Любой инструмент нужно использовать осознанно, в том числе и DoR. Если инструмент не решает никакой проблемы, то есть большая вероятность, что команда бесполезно потратит время на его создание. На практике он станет просто бесполезным артефактом. Опытный Скрам Мастер сможет определить, когда команда достаточно созрела для внедрения DoR.

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

Другой тип историй – несоставные истории. Такие User Stories нельзя декомпозировать. Есть ряд причин, почему большие/несоставные истории, перетекающие из спринта в спринт, плохо влияют на работу команды и продукт в целом. Вот лишь некоторые из этих причин:

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

Использование точек прогресса (Progress Points) для отслеживания достижений

Итак, что же в такой ситуации должна делать Agile-команда?

Когда нельзя найти подходящего способа декомпозировать User Story, нужно искать точки прогресса. 

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

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

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

Примеры точек прогресса 

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

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

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

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

Использование точек прогресса в Scrum 

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

А как вы решаете проблему сложных User Stories? 

Сталкивались ли вы с подобной проблемой в вашей команде? Как вы решали эту проблему? Что еще вы пробовали, чтобы сделать более предсказуемой и управляемой работу со сложными историями? Пожалуйста, поделитесь своими мыслями в комментариях ниже.

Список литературы

Оригинал статьи

Давайте сравним русские названия книг про Agile, придуманные гениями-маркетологами и оригинальные английские.

  1. «Scrum. Революционный метод управления проектами». Джефф Сазерленд— оригинальное название— «Scrum: The Art of Doing Twice the Work in Half the Time». Начнем с того, что Скрам — это не метод и совсем не про проекты. Если обратиться к определению из Скрам Гайда, то Скрам — это фреймворк для разработки, поддержки и поставки сложных продуктов. Про разницу между проектом и продуктом можно почитать здесь. На самом деле у книги и так было яркое оригинальное название. К тому же, этот русский вариант названия «подкинул дров» в конфликт между сообществом Проектного управления и сообществом, развивающим Agile. Начались глупые заявления, что больше проектные менеджеры не нужны, PMBoK не актуален и можно сворачивать проектный офис в своей компании.
  1. «Канбан. Альтернативный путь в Agile». Дэвид Андерсон— оригинальное название— «KANBAN Successful Evolutionary Change for Your Technology Business». Изначально Алексей Пименов предложил издательству название «Канбан. Альтернативный путь в agility», но для маркетологов между Agile и Agility разницы никакой нет. Для справки: Канбан не имеет отношения к Agile и развивается внутри совсем другого сообщества. Кстати, во всем мире эта книга синего цвета. Ее так и называют в разговоре «blue book». В России книгу сделали красного цвета, что двигало маркетологами — непонятно.
  1. «Agile менеджмент: лидерство и управление командами». Юрген Аппело— оригинальное название— «Management 3.0: Leading Agile Developers, Developing Agile Leaders». Аналогично: во всем мире книга известна под названием Менеджмент 3.0, но в России название эджализовали.

Это лишь вершина айсберга

Большинство книг в процессе перевода на русский язык подвергается всевозможным искажениям. До нас идеи автора доходят сквозь призмы восприятия переводчика, редактора и маркетолога. Вдобавок, есть еще наше собственное искаженное восприятие, от которого нам никуда не деться. Что уж тут говорить: даже Скрам Гайд переведен с искажениями, хотя и не такими критичными.  Впоследствии мы часто слышим, что Agile не работает, а самоорганизующиеся команды — это все пустые мечты.

Тем временем на улицах открываются agile-кофейни, прачечные, парикмахерские и т. д. Ничего не поделать, желающих заработать на хайпе в любой стране много. На сайте Head Hunter компании размещают вакансии с названиями Scrum Master/Project Manager. Они даже не подозревают, что любого адекватного Скрам Мастера может только отпугнуть такое словосочетание. Где-нибудь на просторах интернета Вася рассказывает, что он попробовал внедрить Скрам в своей команде разработчиков, и не взлетело.

Где искать правду?

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

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

Владелец Продукта (Product Owner) отвечает за достижение максимальной ценности продукта и работы, которую делает команда.

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

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

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

Обязанности Владельца Продукта

  • Формирование видения продукта
  • Управление ROI (окупаемость инвестиций)
  • Управление ожиданиями заказчиков и всех заинтересованных лиц
  • Предоставление понятных и исчерпывающих требований команде
  • Управление Бэклогом Продукта
  • Взаимодействие с командой и заинтересованными сторонами

Управление Бэклогом Продукта включает

  • ясное и понятное описание элементов Бэклога Продукта
  • управление порядком элементов Бэклога Продукта
  • оптимизацию ценности работы
  • обеспечение доступности, прозрачности и ясности Бэклога Продукта для всех участников процесса
  • обеспечение доступности, прозрачности и ясности запланированного объема работ для всей Скрам команды

Кто такой Владелец Продукта?
Может ли быть Владельцем Продукта не один человек, а несколько в рамках одного продукта?
Что наиболее характеризует Владельца Продукта?

Ежедневный Скрам (Daily Scrum) – это мероприятие, на котором в течение 15 минут Команда Разработки синхронизируется и планирует работу на ближайшие 24 часа. Ежедневный Скрам помогает продвижению к Цели Спринта и выявляет, насколько команда продвинулась с момента предыдущего Ежедневного Скрама. Также мероприятие служит для прогноза того, что может быть сделано до следующей встречи. Это мероприятие проводится в одном и том же месте, в одно и то же время для повышения продуктивности команды, что в данном случае вырабатывает дисциплинированность и собранность.

Длительность: 15 минут

Участники: Команда Разработки

Форматы Daily Scrum

Команда Разработки сама определяет формат встречи. К примеру, в предыдущих версиях Скрам Гайда (Scrum Guide) предлагался формат, при котором каждый из Команды Разработки отвечает на следующие 3 вопроса:

  • Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта? 
  • Что я сделаю сегодня для того, чтобы помочь Команде достигнуть Цели Спринта? 
  • Вижу ли я препятствия для себя или Команды, которые могли бы затруднить достижение Цели Спринта?

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

Практики для Daily Scrum:

Stand Up

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

Правило одного маркера

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

Кто может присутствовать на ежедневном скраме?
Какая роль скрам мастера на ежедневном скраме?
Что есть на входе и выходе у ежедневного скрама?

Обзор Спринта (Sprint Review) – встреча в конце спринта, на которой Cкрам Команда показывает заинтересованным лицам Инкремент с целью получить обратную связь о проделанной работе. Полученная информация служит основанием для обсуждения следующих шагов по оптимизации ценности продукта.

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

Иногда Обзор Спринта путают с Демо.  Однако Обзор Спринта это нечто большее. Демо ( демонстрация готового функционала) — это только часть данного мероприятия.

Проводит встречу Владелец Продукта при поддержке Команды Разработки. Скрам Мастер следит за тем, что мероприятие состоялось, и его цель достигнута.

В таблице ниже представлена информация о том, что мы инспектируем и адаптируем на Обзоре Спринта.

Инспекция Адаптация
  •  Цель Спринта
  •  Готово/Не готово
  •  Проблемы и как их решали
  •  Инкремент
  •  Ситуация на рынке
  •  Метрики
  • Бэклог Продукта
  • Обратная связь от SH*
  • Бизнес цели на ближайшие спринты
  • Формат Обзора Спринта
  • Даты релизов

SH* (от англ. stakeholders) заинтересованные лица.

Давайте разберем каждый пункт более подробно.


Инспекция


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

Готово/ Не готово. В этой части все просто. Владелец Продукта говорит, что из запланированного было сделано, а что нет, и почему так произошло. Тут важно еще раз подчеркнуть, что это не отчет. Это не должно звучать как оправдания. Просто рассказ о трудностях и обстоятельствах, которые произошли за Спринт и их последствия. 

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

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

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

Метрики. Это важная часть Обзора Спринта. Про основные продуктовые метрики в Agile вы можете почитать в нашей статье Метрики в Agile. Без метрик сложно оценить успех или неудачу от определенного решения или проделанной работы. Наличие продуктовых метрик обеспечивает прозрачность на уровне бизнеса.


Адаптация


Бэклог Продукта. Обязательной частью Обзора Спринта считается сбор обратной связи. По результатам в Бэклог Продукта могут быть внесены изменения.

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

Бизнес цели на ближайшие спринты. Хорошей практикой является просмотр Road Map продукта на Обзоре Спринта. По окончанию каждой итерации можно вносить в него изменения. Эта информация должна быть открытой для всех заинтересованных лиц. Также Владелец Продукта может поделиться «взглядом в будущее» и рассказать на чем команда будет фокусироваться в ближайшее время. 

Формат Обзора Спринта. В конце мероприятия можно спросить понравился ли формат Обзора Спринта. 

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

 


Форматы Sprint Review


Презентация

Это классический вариант демонстрации инкремента. Команда показывает проделанную работу в формате презентации. Здесь заинтересованные лица выступают в качестве слушателей и задают вопросы. Данный способ считается наименее эффективным, потому что не всегда помогает удерживать внимание аудитории. Также важно отметить, что в процессе презентации должно быть живое демо продукта (не на слайдах). Если демо не происходит, то встречу уже нельзя назвать Sprint Review. В идеале Скрам Команда должна стремиться сократить до минимума или совсем не прибегать к слайдам, а показывать все вживую. 

Выставка

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

Анкетирование

Всем участникам Sprint Review раздается анкета, в которой задаются такие вопросы как:

Какова вероятность того, что вы порекомендуете продукт, и почему?

Ваши эмоции после ознакомления, и почему? и т.д.

Вопросы могут быть разными – это зависит от специфики работы Скрам Команды

DAKI

Каждый участник Обзора Спринта выражает свое мнение в формате ответа по четырем пунктам:

Delete: Что одно вы бы удалили из инкремента

Add: Что одно вы бы добавили в инкремент

Keep: Что одно вы бы сохранили в инкременте

Improve: Что одно вы бы улучшили в инкременте

Длительность:  не больше 4 часов для Спринта в 1 месяц  
Участники:  Скрам Команда + Заинтересованные стороны (Stakeholders)

PBR (Product Backlog Refindment) —  это деятельность, направленная на уточнение, оценку и упорядочивание элементов в Бэклоге Продукта. Важно понимать, что PBR это не встреча, а активность в рамках которой у команды могут быть встречи.

Во время этой активности участники могут:

  • Детализировать описания элементов Бэклога Продукта
  • Обновлять критерии приемки
  • Декомпозировать крупные истории/задачи на мелкие
  • Оценивать сложность работы
  • Дополнять пользовательские истории/задачи скетчами дизайна и взаимодействия пользователей, тест-кейсами и примерами
  • Обсуждать способы реализации задач

Скрам Мастер на PBR фасилитирует встречу по необходимости и коучит/обучает команду на предмет декомпозиции и оценки задач.
Владелец Продукта отвечает на вопросы команды и помогает декомпозировать задачи так, чтобы они имели ценность с точки зрения бизнеса.

Участники: Скрам Команда + заинтересованные лица

Длительность: рекомендуется не более 10% от времени всего Спринта

Definition Of Done (DoD) — критерии, определяющие степень готовности задачи.

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

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

Критерии готовности, которые выбрала команда, это открытая информация, доступная всем заинтересованным лицам. Их наличие обеспечивает прозрачность, как внутри команды, так и во вне по отношению ко всей организации. Со временем команда улучшает критерии готовности путем ретроспективных изменений. Уровень DoD является показателем зрелости команды.

DoD в LeSS

Если продукт развивают несколько команд, использующих LeSS-фреймворк, то критерии готовности должны быть общими. Другими словами, нужен единый Definition of Done.

Пример DoD Scrum команды

  • Код опубликован на Dev среде
  • Unit тесты пройдены
  • Истории соответствуют реализации
  • Автотесты
  • Регресс пройден
  • CRQ — done

Пример DoD Kanban команды

Аналитика

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

 Разработка

  • Созданы отдельные ветки(а)
  • Выдержан CodeStyle
  • Unit-тесты написаны, пройдены и/или не уменьшено общее покрытие
  • Указаны компоненты (Jira)
  • Компоненты задачи раскатаны на тестовой/превью среде
  • скрипты SQL подготовлены(лежат в нужных папках) и присутствуют в конфигурации
  • Указан сервер в задаче (Jira)
  • Создан(ы) Pull Request
  • Пройдено код ревью
  • Команда проинформирована  о влиянии новых доработок

Тестирование

  • В чек-листах указана связь с требованиями (Traceability) и задачами в Jira
  • Созданные по фиче чек-листы прошли ревью со стороны тестирования, разработки и аналитики
  • Все чек-листы успешно пройдены
  • Выполнены функциональное и регрессионное виды тестирования
  • При необходимости также должны быть выполнены интеграционное, нагрузочное и др. виды тестирования, применимые для фичи
  • Успешно пройдены и заапрувлены приёмо-сдаточные испытания: UAT или Demo
  • Нет открытых дефектов по выводимой фиче.
  • Автотесты написаны в запланированном объёме
  • Сформирована автоматизированная отчётность с результатами прохождения чек-листов и автотестов

 

Definition of Ready

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