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

Контекст

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

• быстрые циклы обучения
• высокая адаптивность
• работа над самым важным.

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

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

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

Митоз

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

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

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

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

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

Подготовка

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

• Аудит бизнес-подразделения (Go See)
• Однодневный обзорный тренинг для топ-менеджмента по организационному дизайну (Designing Agile Organizations)
• Глубокий трехдневный тренинг по LeSS (Certified LeSS Practitioner) для менеджмента, Владельцев Продуктов и техлидов.
• Определены границы продукта как экосистема для малого и среднего бизнеса

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

• Обсуждение плана фасилитации со Скрам-мастером кластера с фокусом на то, что четыре разработчика удаленщики.
• Создание презентации, подготовка цели/агенды/желаемых результатов встречи.

Зачем митоз и профессиональный Скрам

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

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

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

Ограничения и самоорганизация

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

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

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

1. Definition of Done (DoD)
2. Web-разработчик должен оказаться в одной из команд и не быть путешественником
3. Смешанный гендерный состав (парни, девушки)
4. Смешанный состав inhouse и outsource разработки
5. Владение казахским, английским и русским языками.
6. В каждой команде удаленщики.

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

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

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

Воркшоп по самоорганизации

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

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

Названия и метафоры команд

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

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

Нормы взаимодействия

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

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

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

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

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

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

Дальнейшие шаги

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

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