Делимся кейсом митоза — разделения большой команды из 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). Приходите, будет интересно, а главное, очень полезно.

Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.