Как лучше всего провести обзор спринта, если в спринте была работа для нескольких клиентов?

Я работаю в digital-агентстве agile-менеджером проектов. Недавно мы перешли на Scrum.

Мы стремимся объединить всю нашу проектную работу для нескольких клиентов во всеохватывающие 2-недельные спринты, а не 2-недельные спринты для каждого проекта.

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

Мысли?

Это анти-шаблон и попахивает проблемой X/Y. Пожалуйста, предоставьте некоторый дополнительный контекст, объясняющий движущие силы процесса для этого, а также то, какую существующую проблему вы пытаетесь решить, и почему вы считаете, что подход «команда для каждого проекта» вам не подходит. Кроме того, учтите, что если вы собираетесь прервать процесс Scrum по «причинам», то Scrum может оказаться для вас неподходящим фреймворком.
Нередко Scrum используется для работы с несколькими клиентами, но обычно у Sprint есть какая-то общая тема. Работа в чем-то связана по своему характеру и в конце делается какая-то подача. Не могли бы вы уточнить, почему вы используете Scrum вместо других инструментов или фреймворков, таких как Kanban?

Ответы (3)

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

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

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

2- Многоступенчатая демонстрация: первая демонстрация ориентирована на непосредственных заинтересованных лиц. Затем владелец продукта назначает последующие демонстрации с другими группами заинтересованных сторон.

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

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

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

Или это потому, что работа для этих нескольких клиентов естественным образом поддается объединению в единую цель спринта?

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

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

Простой ответ — сроки и укрепление доверия . У нас есть сроки, которые мы должны уложиться, поскольку клиенты планируют запуски и т. д., и мы должны видеть, что мы продолжаем работать над проектами и поставлять программное обеспечение после каждого спринта, чтобы завоевать доверие клиентов. Однонедельные спринты могли бы быть вариантом, но я лично обнаружил, что они слишком часты, и страдает скорость.
@DanKastelik Возможно, вы слишком многого требуете от agile/scrum. Ни один из них не гарантирует больше или меньше, чем другие подходы к достижению сроков или укреплению доверия. Действительно, плохо реализованный Agile также может работать против вас: недельные спринты могут пойти ужасно неправильно, как и постоянно пропущенные спринты с точки зрения доверия клиентов. Agile — это не серебряная пуля; вам по-прежнему необходимо тщательно планировать и управлять своими клиентами и командой, что можно сделать с помощью любой методологии. Как и все остальные здесь, я согласен: тщательно обдумайте , почему вы используете скрам, потому что я не думаю, что ваше обоснование складывается.

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