Как свести время скрама к минимуму в большой команде разработчиков

Моя компания всегда использовала что-то вроде Agile-процесса. Мы проводим скрамы три раза в неделю. Менеджер по разработке — это в основном Scrum Master (SM), а Team Lead — альтернативный/резервный SM.

Раньше у нас была небольшая команда из 5 или 6 человек, и время, затрачиваемое на схватку, никогда не было проблемой, потому что мы ограничивали его примерно 15 минутами.

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

Менеджер/SM теперь считает, что время является проблемой, и было реализовано несколько изменений.

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

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

У кого-нибудь еще были проблемы с управлением большой схваткой? Было ли что-то, что вы сделали, чтобы сократить количество времени, затрачиваемого на это?

Я не пытаюсь узурпировать управление, просто в последнее время я больше об этом думаю.

Интересно, может ли это лучше подойти для pm.stackexchange.com?
Близкий дубликат в Project Management SE: ежедневная встреча с несколькими командами Scrum
О каких цифрах идет речь в исходной «маленькой команде» и новой команде «маленькая команда + недавно нанятое количество новых людей»?
@Carson63000 Раньше нас было около 5 или 6, сейчас нас около дюжины.
Спасибо, Кевин, я отредактировал ваш вопрос, чтобы добавить эту информацию.

Ответы (3)

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

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

Одним из быстрых и простых способов является использование шаблона «Стойка на 30 секунд» .

Это хороший совет, тем более что, учитывая добавленную дополнительную информацию, стендап в настоящее время занимает от двух с половиной до трех минут на человека. Но на самом деле нехорошо иметь ответ StackExchange, который является просто ссылкой на внешнюю статью. Гораздо лучше обобщить информацию, а затем предоставить ссылку — что произойдет, если блог этого парня отключится или переместится?
@Hugo, не кидай сюда ссылку. Другой сайт может исчезнуть. Процитируйте соответствующие части, пожалуйста.

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

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

Как свести время скрама к минимуму в большой команде разработчиков
СпросиСетьПолитика конфиденциальности1y, 0v