Митоз и экспресс-старт команд

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

Мы находимся в процесс Agile-трансформации бизнес-юнита, в котором 15 команд и выделенные функции (маркетинг, журнал, CRM) создают продукт экосистема для малого и среднего бизнеса. В текущей структуре за каждой командой закреплен локальный Владелец Продукта и Бэклог Продукта. В целевой картине организационная структура состоит из нескольких кластеров или областей ценностей (Value Areas), в которых находятся 4 и более фиче-команд, работающих из общего Бэклога Продукта. Почему? Так организация сможет развить способности, которые менеджмент считает ключевыми для реализации бизнес-стратегии:

На Рис. 1 вы можете видеть текущую и целевую картины каждого кластера

(Рис. 1: текущая и целевая структура продуктового кластера)

Пилотной областью ценности (Value Area) были выбраны кредиты, но в кластере платежи находилась большая команда из 19 человек, которая собиралась делиться на две и специализироваться, закрепив за новыми командами локальные очереди и Владельцев Продуктов. Мы предложили масштабироваться правильно и использовать Скрам-паттерн митоз.

Типичный подход к масштабированию — специализация команд. Мы называем это продуктовой фрагментацией. Со временем такой подход разрушает адаптивность и вызывает ряд проблем (Рис. 2):

(Рис. 2: продуктовая фрагментация)

Мы рекомендуем использовать Скрам-паттерн митоз, при котором дочерние клетки полностью наследуют свойства родительской. Это значит, что команды не специализируются и продолжают фокусироваться на всем продукте целиком (Рис. 3).

(Рис. 3: митоз команд)

Подготовительная работа на уровне организации:

Непосредственная подготовительная работа к воркшопу:

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

Затем мы обсудили Agile-трансформацию и место кластера платежи в ней, целевую организационную структуру бизнес-подразделения. Закрыли вопросы разработчиков, которые касались событий масштабируемого Скрама: общего Планирования, мульти-командного PBR-а и Ретроспективы. После этого мы были готовы продолжить движение.

При формировании команд разумно полагаться на самоорганизацию, потому что контекст комплексный и нет очевидных решений. Люди, делающие работу, найдут наилучшую композицию команд. Кроме того, более вероятно, что разработчики возьмут ответственность за результат. Самоорганизация происходит с целью и четкими правилами/ограничениями. Люди демонстрируют сложное поведение внутри простых границ (Рис. 4).

(Рис. 4: цель, ограничения и самоорганизация)

Единственное ограничение, с которого мы начали — Definition of Done (DoD). Мы предложили, объединившись в малые группы, за пять минут найти дополнительные ограничения. После этого в открытой дискуссии получили список критериев, который был поддержан консенсусом:

Консенсус искали с помощью римского голосования (Рис. 5).

(Рис. 5: римское голосование)

После этого были готовы формировать новые команды.

Мы предложили ребятам за 15 мин. сформировать команды и предварительно создали для каждой будущей команды станцию, наклеив на стены электростатическую пленку. Попросили каждого разработчика написать на стикере имя/фамилию. Осталось лишь поместить стикер на станцию, где хочется работать. Мы также разбили удаленщиков на два потока, запустив две Zoom-конференции на ноутбуках и переносили в руках. После первого раунда команды не смогли удовлетворить все условия, которые сами же выработали. Так получилось, что все удаленщики оказались в одной команде.

Нам понадобился второй раунд, в котором я попросил ребят договориться и закрыть проблему самим. В итоге, за полчаса мы сформировали две фиче-команды и команду Владельца Продукта (Product Owner Team).

Человек получает свидетельство о рождении и имя. Чем команды хуже? Для формирования общей идентичности я прошу придумать название и визуализировать метафору команды за полчаса. В метафоре должны быть отображены участники и команда должна уметь объяснить место каждого на картинке. Задание творческое и занимает полчаса. И какое это удовольствие наблюдать со стороны за тем, как группа трансформируется в команду! Затем мы попросили команды по очереди представить названия, метафоры, поощряя задавать уточняющие вопросы. На Рис. 3 вы видите итоговые названия и метафоры команд.

(Рис. 6: названия и метафоры команд)

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

Наладить взаимодействия можно с помощью Скрам-паттерна Norms of Conduct.

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

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

У команд есть договоренность о том, что через несколько Спринтов они могут перемешаться вновь, если найденная композиция окажется неоптимальной. А уже через несколько дней команды отправились на Планирование Спринта.

Мы учимся строить эффективные команды на сертификационном тренинге Professional Scrum Master (PSM). Приходите, будет интересно, а главное, очень полезно.