Ежедневные стендапы с несколькими Scrum-командами

Есть 3 Scrum-команды (~15 человек), чья работа тесно связана, поэтому необходимо, чтобы команды были в курсе прогресса других.

Как можно эффективно обмениваться информацией между командами ежедневно?

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

Знаете ли вы хороший способ держать в курсе подключенных Scrum-команд друг о друге?

Какие были проблемы с делегированием посла? Scrum of Scrums предназначен для решения этой проблемы с участием представителей каждой команды Scrum. Рассматривали ли вы выбор представителей, формат встречи или другие причины, по которым выбор представителей и проведение Scrum of Scrums не сработали?
@ThomasOwens, то, что описал OP, на самом деле не является Scrum of Scrums.
Рассматривали ли вы внутреннюю систему статусов, похожую на твиттер?
Всего ~ 15 человек в 3 командах Scrum?
... или 3 команды по 15 человек, всего задействовано 45 человек?
Вы можете найти ответы на этот похожий вопрос полезными: pm.stackexchange.com/questions/6230/…
15 человек: 105 каналов связи. 45 человек: 990 каналов связи. Scrum-команды должны состоять примерно из 7 человек, плюс-минус 2, в среднем всего 22 канала связи.
Помимо других вопросов, вы смотрели на структуру Nexus ?

Ответы (7)

Как заметил Томас Оуэнс, одним из решений масштабирования Scrum является Scrum of Scrums. Однако то, что вы описываете в ОП, отличается:

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

Вместо того, чтобы каждая команда отправляла представителя на ежедневный Scrum других команд, Scrum of Scrums представляет собой отдельную встречу более высокого уровня, на которой обычно присутствует по одному представителю от каждой команды. Это может быть не обязательно ежедневная встреча, часто для команды лучше проводить ее 2-3 раза в неделю. И его направленность несколько отличается от Scrums на командном уровне. Совершенно очевидно, что он фокусируется на статусе команды и блокировщиках. Но он также больше ориентирован на быстрое устранение блокировщиков, поэтому он может не иметь строгих ограничений по времени и может (по общему согласию) трансформироваться в сеанс решения проблем, когда это необходимо. Участники могут и должны быть разными, в идеале каждая команда могла бы более или менее регулярно менять своих представителей.

Еще одним подходом к обмену информацией являются сообщества практиков .

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

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

Все нижеизложенное — из моего собственного болезненного опыта:

Быть в одной комнате.

Разговаривайте друг с другом во время работы или в обеденный перерыв.

Самое главное

Обязательно проведите общее собрание со всеми собравшимися (стоя или нет), на котором каждого человека спрашивают:

  • Что ты сделал вчера
  • Над чем ты работаешь сегодня
  • Если есть какие-то проблемы или ему/ей нужна помощь

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

«Большой стендап со всеми участниками — это слишком долго». входил в состав ОП.
Слушайте, я хотел бы писать код не думая и провести день, не занимаясь объяснением простых вещей клиентам, но этого просто не произойдет. Некоторых вещей нельзя избежать навсегда. Как менеджер проекта вы являетесь лидером, и вы должны обеспечивать соблюдение процедур, чтобы убедиться, что проект завершен и все оплачены, вместо того, чтобы угодить всем и провалить проект.
Я Scrum-мастер, а не менеджер проекта, поэтому, к счастью, я не связан с зарплатой членов команды :-) Я понимаю, что это сработало в вашей команде, и это нормально. Однако это не означает, что это автоматически станет лучшим решением для всех команд на планете. Если OP считает, что ежедневные Scrums слишком длинные, жесткое соблюдение процесса, ИМХО, не является правильным ответом (особенно не с точки зрения Agile). Частью определения Scrum является то, что рекомендуемый размер команды Scrum составляет прибл. 5-9 человек. Выше этого мягкого предела Scrum нуждается в корректировках для масштабирования.
Кстати, мне было бы интересно прочитать некоторые более конкретные подробности об опыте, о котором вы говорите выше. Насколько большой была ваша команда? С какими проблемами вы столкнулись и как вы их решили? Я думаю, что все мы здесь открыты для веских аргументов и рады учиться на хорошо написанных ответах. К сожалению, ваш ответ в его нынешнем виде не дает нам многого для изучения :-(
@Peter, извините, что не дал вам подробностей, так как я пишу эти сообщения случайным образом на работе. В настоящее время я управляю командой из 9 человек, и встречи необходимы. Когда люди вынуждены говорить о себе перед другими людьми, у них появляется чувство ответственности, а также они слышат, что сделали другие. Это дает вам две вещи: насколько вы хороши по сравнению с другими, и вы узнаете о ходе всего проекта, поэтому вы действительно знаете, почему для вас важно завершить эту задачу сегодня (потому что команда контроля качества ждет, пока вы закончите эту функциональность, чтобы они могли ее протестировать)
@Peter: Я пытался избегать таких «больших встреч», чтобы «не утомлять» разработчиков и «не тратить их время» (поскольку встреча с 9 разработчиками и 2-3 менеджерами занимает не менее 20-60 минут). Результатом избегания этого стало то, что люди стали еще больше отсоединяться друг от друга, и возникло недопонимание. Проще говоря: заставьте людей встречаться и разговаривать друг с другом любой ценой. Большинству разработчиков (или рабочих в целом) это не нравится, потому что они либо слишком застенчивы, либо слишком заняты, но вы обязаны следить за тем, чтобы эти встречи происходили. Надеюсь, я помог.
Я полностью согласен с тем, что только потому, что членам команды что-то не нравится, это не является веской причиной, чтобы не делать этого, если в противном случае это принесет команде явные преимущества в долгосрочной перспективе. Однако команда должна понять — и со временем испытать на себе — почему это требуется и почему это хорошо для них. Так что, ИМХО, мы должны обучать их и убеждать, а не заставлять их подчиняться. Если они не видят пользы, можем ли мы показать или продемонстрировать ее им? ИМХО, это вызов скрам-мастеру/ПМ, а не недостаток команды.
Я согласен с Gangsta IRL — собрать всех на одной встрече очень полезно. Если встречи занимают слишком много времени, важно провести их «по делу». Знания, которыми делятся на таких встречах, по моему опыту, приносят выдающиеся результаты. Время от времени разработчик, работающий над проектом А, выслушает проблему, поднятую кем-то из проекта Б, и предложит решение, которое сэкономит несколько часов работы и разочарований. В моей команде мы также проводим ежемесячные встречи «Обмен знаниями», на которых мы обсуждаем более длинные, избранные темы.

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

Это простое изменение, но я думаю, что это очень важное изменение в этой ситуации. Важнее объяснить достигнутую цель, чем способ ее достижения.

Я согласен с опытом Hellen.

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

  • Супер-стендапы имеют ограниченный интерес для участников. Их роль заключается в том, чтобы держать руководство в курсе.
  • Получить инструмент командного чата . Если у кого-то есть публичное объявление, он может передать его через чат. HipChat от Atlassian специально разработан для команд: например, если кто-то упоминает вас в общедоступной комнате или если вы отсутствуете, он отправляет вам электронное письмо в чат.
  • Получите командную вики . Например, в Atlassian Confluence каждый раз, когда кто-то обновляет просматриваемую вами страницу (например, статус каждого серьезного изменения), все получают уведомление.

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

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

В этом контексте я настоятельно рекомендую iDoneThis .

По сути, iDoneThis отправляет электронное письмо всем в вашей команде (то есть, в данном случае, всем в ваших 3 командах Scrum), и каждый человек пишет быстрый ответ на электронное письмо о том, что они сделали в этот день (вы можете отправить его в любое время). ты хочешь). На следующий день iDoneThis отправляет дайджест всей команде с этими ответами.

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

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

Я думаю, что по-прежнему важно время от времени проводить общие собрания команды, но для ежедневного обновления это идеально.

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

Примечание: это также здорово использовать в качестве инструмента только для себя («рабочий дневник», если хотите). Для этой цели (1 человек), это бесплатно. Вот как я использую его сейчас и люблю его.

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

У проблемы есть два аспекта.

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

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

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

б. Он создает автоматические минуты в конце. Каждый участник получает уведомление с итоговым протоколом. Также скрам-мастер получает список заблокированных элементов.

в. Таймер, чтобы закончить встречу вовремя.

С учетом вышеперечисленных возможностей стендап даже для 15 человек займет не более 15-20 минут.

Вы можете зарегистрироваться и начать использовать его для своей команды в течение 30-дневного бесплатного пробного периода.

Ежедневные стендапы с несколькими Scrum-командами
СпросиСетьПолитика конфиденциальности1y, 0v