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

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

Если вы разделяете свою работу на четыре направления, «вы» не можете использовать Scrum.

• Вы могли бы сделать, как вы говорите. Продолжайте использовать Scrum и переопределяйте роли и обязанности, а также реорганизуйте команды, в основном пытаясь создать отдельные команды для каждого продукта, при этом вы занимаете «более высокую» позицию в качестве роли менеджера/консультанта/поддержки или того, что подходит для работы по поддержке. что ты делаешь, или...
• вы позволяете другим командам использовать Scrum в своих проектах, в то время как для двух проектов, которыми вы занимаетесь + дополнительная поддержка, «вы» переключаетесь на Kanban. Это позволит вам лучше визуализировать то, что происходит со всем, получить больше информации и знаний, а затем принять более обоснованные решения.

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

Что бы вы ни решили делать, вам нужно проанализировать всю ситуацию и увидеть, где болевые точки, и только потом решить, что делать: продолжать использовать Scrum во всех командах, реорганизовать команды, реорганизовать роли, использовать Канбан во всех командах, использовать и то, и другое. Канбан и Скрам и др.

Стоит ли просить менеджера чередоваться и работать только над двумя продуктами вместо 4 во время спринта или релиза? Да, это короткий ответ.

Работа со многими продуктами одновременно, как с общим ресурсом, всегда будет сложной задачей, независимо от того, какой способ работы вы применяете (например, в данном случае Scrum).

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

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

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

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

Должны ли мы разделить команду на 3 и переопределить обязанности и роли?

Похоже, это было бы очень полезно как для вас в вашей роли, так и для членов вашей команды. Это поможет избавиться от некоторых дел, чтобы вы не чувствовали, что вам нужно постоянно проверять, а также даст другим возможность принимать собственные решения, не полагаясь на вас так сильно. В Интернете есть много ресурсов для простых сеансов R + R, посмотрите этот или напишите мне в DM, и я могу поделиться с вами простым в использовании шаблоном.

Есть ли другие решения?

Мне интересно, нужно ли обсуждать более широкую реорганизацию? А также R+R с более высокого уровня? например, попросить генерального директора отступить и позволить команде продолжить свою работу, не отвлекаясь. Трудно сосредоточиться и что-то сделать, если начальник всегда вставляет: «сделай это сейчас/сейчас/вместо этого».

В зависимости от того, насколько вы велики, плоские иерархии могут способствовать сотрудничеству и разрушению барьеров или способствовать анархии. Так что, если вы растущая организация, возможно, стоит подумать о внедрении некоторых ступеней. Не для того, чтобы создать культуру «должно быть одобрено», а для того, чтобы помочь определить R + R, чтобы вы все могли сосредоточиться на своей работе. Возможно иметь как иерархию, так и сверхоткрытую, честную культуру сотрудничества!

Надеюсь, это полезно!

РЛ.