Делимся кейсом митоза — разделения большой команды из 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). Мы предложили, объединившись в малые группы, за пять минут найти дополнительные ограничения. После этого в открытой дискуссии получили список критериев, который был поддержан консенсусом:
- Definition of Done (DoD)
- Web-разработчик должен оказаться в одной из команд и не быть путешественником
- Смешанный гендерный состав (парни, девушки)
- Смешанный состав inhouse и outsource разработки
- Владение казахским, английским и русским языками.
- В каждой команде удаленщики.
Консенсус искали с помощью римского голосования (Рис. 5).
(Рис. 5: римское голосование)
После этого были готовы формировать новые команды.
Воркшоп по самоорганизации
Мы предложили ребятам за 15 мин. сформировать команды и предварительно создали для каждой будущей команды станцию, наклеив на стены электростатическую пленку. Попросили каждого разработчика написать на стикере имя/фамилию. Осталось лишь поместить стикер на станцию, где хочется работать. Мы также разбили удаленщиков на два потока, запустив две Zoom-конференции на ноутбуках и переносили в руках. После первого раунда команды не смогли удовлетворить все условия, которые сами же выработали. Так получилось, что все удаленщики оказались в одной команде.
Нам понадобился второй раунд, в котором я попросил ребят договориться и закрыть проблему самим. В итоге, за полчаса мы сформировали две фиче-команды и команду Владельца Продукта (Product Owner Team).
Названия и метафоры команд
Человек получает свидетельство о рождении и имя. Чем команды хуже? Для формирования общей идентичности я прошу придумать название и визуализировать метафору команды за полчаса. В метафоре должны быть отображены участники и команда должна уметь объяснить место каждого на картинке. Задание творческое и занимает полчаса. И какое это удовольствие наблюдать со стороны за тем, как группа трансформируется в команду! Затем мы попросили команды по очереди представить названия, метафоры, поощряя задавать уточняющие вопросы. На Рис. 3 вы видите итоговые названия и метафоры команд.
(Рис. 6: названия и метафоры команд)
Нормы взаимодействия
Согласно исследованиям Ричарда Хакмана, одним из ключевых условий развития эффективной команды является выработка норм взаимодействий. С точки зрения системного мышления, это так, потому что:
Эффективность системы определяется взаимодействием частей, а не тем, насколько эффективно они функционируют по отдельности.
Наладить взаимодействия можно с помощью Скрам-паттерна Norms of Conduct.
Для начала мы предложили командам вдохновиться ценностями Скрама: открытость, уважение, фокус, преданность, смелость. Кратко напомнив их смысл, мы дали 15 мин на генерацию конкретных и измеримых паттернов поведения, которые бы их поддержали.
После завершения таймбокса команды представляли примеры поведения в открытой дискуссии. Мы их обсуждали и принимали с помощью римского голосования. Вот некоторые из норм взаимодействия, которые родились у команд:
- Каждая встреча должна иметь агенду, цель, таймбокс и заметки, которые высылаются после завершения.
- Если появляются проблемы, например, баг, то разработчик отвечает за описание проблемы, поиск причины и координацию с заинтересованными лицами.
- Разработчики отвечают за координацию и интеграцию внешних зависимостей вместо того, чтобы идти к Владельцу Продукта.
- На встречах все активно вовлечены, нет отвлечения на посторонние задачи.
Дальнейшие шаги
У команд есть договоренность о том, что через несколько Спринтов они могут перемешаться вновь, если найденная композиция окажется неоптимальной. А уже через несколько дней команды отправились на Планирование Спринта.
Мы учимся строить эффективные команды на сертификационном тренинге Professional Scrum Master (PSM). Приходите, будет интересно, а главное, очень полезно.
