Статья опубликована с разрешения автора Катерины Вековой, Скрам-мастера ManyChat.
Привет! Меня зовут Кейт, и я работаю Скрам-мастером в ManyChat. Этой осенью у меня была крутая возможность разделить одну кросс-функциональную команду из 11 человек на две новые команды. Этим опытом я хотела бы поделиться с другими Скрам-мастерами, Скрам-командами и всеми, кому это может быть полезно.
Процесс разделения команды называется митозом по аналогии с процессом деления клеток. Кембриджский словарь описывает митоз как «тип деления клетки, при котором одна клетка делится на две одинаковые, каждая с тем же количеством хромосом (= клеточных структур), что и исходная клетка». Это определение хорошо описывает, почему авторы книги Scrum Patterns решили назвать один из своих паттернов митозом.
Важно, чтобы каждая новая Скрам-команда оставалась кросс-функциональной после разделения и сохраняла достаточно широкий домен знаний, чтобы иметь возможность автономно доставлять инкремент. Так, каждая новая команда сможет работать над любой частью продукта.
Мы в ManyChat используем митоз, потому что только так мы можем сохранить и передать все накопленные продуктовые, технические знания и культуру из одной команды в две новые.
Как понять, что пора разделять команду
В нашем случае в команде было 11 человек. Туда совсем недавно присоединились новые участники, и после нескольких Спринтов в новом составе мы начали замечать следующее:
- мы стали гораздо больше времени тратить на координацию, принятие решений, вовлечение всех участников на событиях и т.п.;
- команде стало сложнее держать фокус на общем прогрессе в достижении целей Спринта.
Когда все эти трансакционные издержки стали слишком очевидными, мы осознали, что пришло время создать две новые команды из одной огромной команды Godzillaz (также известной как Mobile App Team).
Как разделить компетенции между двумя командами
Мы вместе с Владельцем Продукта посмотрели на выполненные задачи и на элементы Бэклога Продукта, которые планируем взять в ближайшие Спринты. Так мы проанализировали, какие доменные знания самые важные для создания Инкремента.
Затем мы построили таблицу, на которой отметили, кто какими компетенциями обладает. Теперь осталось разделить участников с одинаковыми компетенциями на две команды.
В результате мы наглядно увидели, что действительно готовы создать две автономные команды. Также мы поняли, что для команды A необходимо будет нанять новых инженеров iOS и Android платформ.
Насчет дизайнера команда решила, что он попытается участвовать в жизни двух новых команд. Мы договорились инвестировать время на запуске двух команд, чтобы обсудить структуры, которые поддержат его участие и обмен знаниями между командами.
Фронтенд-разработчик будет только в одной команде. При анализе Бэклога мы выяснили, что в ближайшее время задач для фронтендера будет немного, поэтому нанимать второго разработчика нет необходимости.
Компетенцией знаний о продукте (product knowledge) обладает Владелец Продукта. В Скраме Владелец Продукта всегда один, независимо от количества команд.
Это вся подготовительная работа, которую мы проделали перед встречей с командой для митоза. А чтобы узнать, как пошагово фасилитировать сессию митоза, читайте вторую часть статьи.
