Ежедневный скрам — встреча, привычная для аджайл-команд. Но я всё еще сталкиваюсь с тем, что некоторые владельцы продукта и продакт-менеджеры не уверены, стоит ли им её посещать. В этом посте я собрал рекомендации о том, стоит ли PM и PO посещать эту встречу, когда лучше всего это делать и как в ней участвовать.

Совет 1: Помните, зачем это нужно

Ежедневный Скрам - блог по Аджайл Менеджменту

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

  1. насколько они продвинулись;
  2. что дальше они планируют делать;
  3. нужна ли кому-либо помощь — есть ли затруднения или блоки.

Ежедневный скрам должен проходить быстро — не более 15 минут. Его стоит проводить ежедневно в одном и том же месте в одно и то же время; мне кажется, что лучшее время — утром.

Совет 2: Нужно ли приходить?

Я рекомендую владельцам продукта и продакт-менеджерам участвовать в ежедневном скраме по крайней мере дважды в неделю (см. примечание 1 под статьей). Это помогает понимать, что происходит в текущем спринте, можете ли вы помочь и как. Например, вы можете заметить, что некоторые пользовательские истории выполнены, и можно устроить их обзор; или что команде непонятны некоторые критерии приёмки, и требуются ваши разъяснения. Со своей стороны, вы можете попросить команду уточнить элементы бэклога продукта или, например, обновить дорожную карту продукта (см. примечание 2).

Зачем владельцу продукта приходить на дейли? Обсуждаем на тренинге PSPO

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

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

Совет 3: Не вмешивайтесь

Советы Продакт Оунеру - Скрам тренинги и Сертификации, Ажайл блог brainrain.com.ua

Эта встреча нужна в первую очередь не вам, а команде разработки. Воздерживайтесь от попыток вмешаться в самоорганизованную активность команды: не назначайте задачи, не критикуйте участников лично — это может ослабить автономию команды и её преданность делу. Если у вас вызывает беспокойство, как проходит спринт, скажите об этом честно, но конструктивно. Не указывайте команде, что ей делать. Управлять спринтом и достигать его цели должны участники команды, а вы должны управлять продуктом и полным циклом его релиза (который состоит из нескольких спринтов).

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

Приходите на Professional Scrum Master за подсказками в сложном деле скрам-мастера

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

Совет 4: Предоставьте скрам-мастеру выполнять его работу

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

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

Приходите на тренинг PSM 2 и узнайте о восьми аспектах ответственности скрам-мастера

Примечания

[1] Если вы работаете над крупным продуктом и сотрудничаете с другими людьми, ответственными за этот продукт (владельцами фич или компонентов), обычно вам не нужно посещать ежедневный скрам. Вместо этого вы участвуете в скраме скрамов (SoS) — аналоге ежедневного скрама, который часто используют для фасилитации работы нескольких команд. Мне нравится проводить ежедневные встречи SoS сразу после ежедневных скрамов, куда приходят представители каждой команды разработки.

[2] Имейте в виду, что эта рекомендация идет вразрез с версией Руководства по скраму 2017 года. За годы определение встречи изменилось. Изначально это была открытая встреча, но активно участвовать в ней могли только люди из команды разработки и скрам-мастер (см. Agile Software Development with Scrum). В книге Agile Project Management with Scrum на этой встрече уже разрешается говорить и владельцам продукта (см. стр. 135 и 141). Но независимо от того, какое определение принято в текущий момент, цель ежедневного скрама — дать команде разработки полный контроль над работой в спринте.

Переведено и адаптировано командой BrainRain по материалам статьи Романа Пихлера 20 июня 2017 года.