Слишком большой для масштабирования — руководство по оптимальному размеру команды Scrum

Послушайте аудиоверсию этой статьи.

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

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

• Как сохранить целостность ноу-хау, когда товарищи по команде больше не работают вместе
• Должны ли вы разделяться по функциям (например, фронтенд и бэкэнд команды)?
• Должны ли новые команды иметь отдельные невыполненные работы?
• Должна ли соответственно расти команда управления продуктом?

Когда следует начинать создавать вторую команду?

Самый очевидный признак того, что стоит задуматься о разделении команды или добавлении новой команды, — увеличение вашего бюджета. Это может произойти с новым инвестиционным раундом в стартапе или новыми целями для вашего продукта на предприятии. Если увеличение бюджета настолько существенно, что ваша команда вырастет в 3 и более раз, то вам не составит труда разделить текущую команду для распространения ноу-хау. Однако решения становятся не такими однозначными, когда увеличение бюджета происходит поэтапно, и вы в конечном итоге добавляете в список несколько новых людей. Если, скажем, вы планируете увеличить свою команду с 7 до 11 человек, нужно ли для этого разделение? Agile продвигает небольшие команды, но также продвигает отдельных людей и взаимодействие, а не процессы и инструменты. Наличие двух или более команд неизбежно создает больше процессов, которые могут работать синхронно.

Что говорят эксперты?

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

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

Эти цифры кажутся интуитивно понятными, но за ними стоит и некоторая математика. Если вы думаете о команде, каждый человек подобен узлу, и они связаны с другими узлами. Это межличностные отношения между товарищами по команде. Они могут быть дружелюбными, соревновательными, злобными или заботливыми. Какими бы ни были отношения между двумя людьми, это все равно связь, которая требует от каждого человека определенных умственных способностей. По мере роста команды количество этих ссылок не растет линейно. Формула связи между узлами: \(n(n-1)/2\). Вот график прироста ссылок:

Диаграмма ясно иллюстрирует с математической точки зрения, почему команды работают наиболее эффективно, когда они не слишком велики. Если мы возьмем от 3 до 9 членов команды, предложенных в Руководстве по Scrum, мы получим от 3 до 36 ссылок. Если бы мы выросли до 15 человек, у нас было бы более 100 ссылок. Такая команда могла бы работать эффективно только в том случае, если бы их обязанности были очень четко определены и редко пересекались, или если бы существовали какие-то неофициальные подгруппы. Ни то, ни другое не желательно, если вы работаете на основе Agile-принципов.

Признаки того, что команда становится слишком большой

Ежедневный Скрам

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

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

Уход и планирование спринта

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

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

Ретроспектива

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

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

Как разделить команду

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

Боевой дух команды

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

Межфункциональные команды

Scrum продвигает кросс-функциональные команды, «со всеми навыками команды, необходимой для создания приращения продукта». Это верно при масштабировании до двух или более команд. Для многих разработчиков, особенно новичков в Agile, естественной тенденцией является мыслить параллельно техническим направлениям. Например, команды часто хотят разделить на back-end и front-end команды. В некоторых редких случаях это может иметь смысл, но в большинстве случаев вы, как менеджер по продукту, не должны этого делать. Команда, состоящая из фронтендеров, не в состоянии самостоятельно реализовать инкремент продукта и, естественно, начинает больше думать о технических возможностях, что их и объединяет. Вместо этого они должны сосредоточиться на клиенте и на том, как удовлетворить его потребности.

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

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

Должны ли команды иметь отдельные бэклоги?

Если команда разделена, то возникает естественный вопрос: должны ли они работать над одним и тем же бэклогом или у них должны быть отдельные бэклоги. Мы можем обратиться к Scaled Agile Framework за руководством.

Scrum@Scale

Scrum@Scale — это методология, разработанная создателем Scrum Guide. Scrum@Scale не очень предписывает и не описывает конкретно, как обрабатывать невыполненные работы по продукту. Однако он отмечает два момента:

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

Таким образом, по сути, Scrum@Scale представляет новые команды с их собственными PO и невыполненными работами. Он просто добавляет некоторые дополнительные структуры для координации работы между командами. Scrum@Scale лучше всего работает с несколькими, десятками или сотнями команд, но может дать ценную информацию, даже если вы работаете с двумя командами.

Крупномасштабный Scrum (LeSS)

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

Как быть в курсе

Для менеджера по продукту наличие нескольких команд означает больше работы по отслеживанию прогресса и ответам на запросы.

Расставьте приоритеты для совещаний

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

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

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

Участвуйте больше со Scrum Masters

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

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

Введение Scrum of Scrums

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

Рассмотрите возможность расширения продуктовой команды

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

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

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

Заключение

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

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

Все это указывает на то, что вам, возможно, придется разделить команду. Разделение команды кажется простой задачей, но оно также имеет долгосрочные последствия, и каждый менеджер по продукту должен учитывать несколько моментов при этом:

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

Отслеживание двух или более команд потребует от вас расстановки приоритетов. Эффективный менеджер продукта должен планировать, как он будет идти в ногу с новыми командами:

• Отдавайте приоритет встречам. Подумайте, какие Agile-церемонии стоят вашего времени, а какие можно проигнорировать.
• Взаимодействуйте со скрам-мастерами. Используйте скрам-мастеров в качестве доверенных лиц вашей команды и собирайте от них информацию.
• Расширяйте продуктовую команду. Добавьте людей, которые будут работать вместе с вами и помогать с ежедневными повторяющимися задачами или проводить исследования пользователей и анализ рынка.

Используя эти предложения, вы сможете четко разделить команду. Если ваши команды продолжают расти и в будущем вы добавите еще больше команд, вам следует прочитать о Scaled Agile Framework, которая предоставляет рекомендации по структуре и процессам для Agile в масштабе.