Хороший подход к группированию различных историй проекта в одних и тех же спринтах

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

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

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

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

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

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

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

Кроме того, в заключение спросите себя, почему вы хотите это сделать. Буквально нет причин когда-либо рассматривать это; вы можете просто делать оба проекта последовательно. Завершите проект А, а затем завершите Б, как только будет выполнен А; если вы могли бы успешно выполнить оба задания параллельно, то вы всегда сможете выполнить их быстрее последовательно. Любые причины запуска обоих сразу, вероятно, коренятся в том, что вы уже признали себе, что вы все равно потерпите неудачу в обоих проектах, и пытаетесь смягчить ущерб, имея что- то , что можно показать в крайний срок, чтобы убедить людей, что вам нужно больше времени . /деньги без их вытаскивания. Потратьте свое время на решение этой проблемы и предоставьте своим людям возможность сосредоточиться на чем-то одном, так они будут работать лучше всего.

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

• Один человек может быть только в одной команде ⁽¹⁾
• Скрам-мастер работает в команде , а не в проекте.

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

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

⁽¹⁾ (мой опыт подсказывает мне, что любой способ обмануть это правило потерпит неудачу, потому что не может быть ни концентрации , ни приверженности , двух из пяти основных ценностей, если кто-то состоит в нескольких командах).

Это ужасная идея

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

Это сценарий двойной связи из учебника.

Преимущества наличия историй из нескольких проектов в каждом спринте:

• Вы увидите прогресс более чем в одном проекте
• Разработчики могут наслаждаться разнообразием

Недостатки:

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

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

но у вас есть несколько мастеров Scrum (по одному на проект) и одна команда

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