Внимательно изучив книгу Team Topologies, представляю вам свое мнение по поводу прочитанного.
Team Topologies НЕ про Agile-организацию
Достаточно взглянуть на обложку, чтобы понять, что главная цель, которой задаются авторы, не построение не Agile-организации, а ускорение потока создание ценности. На обложке находим: “организация бизнеса и технических команд для быстрого потока”.
В книге находим подтверждения, что авторы оптимизируют иключительно скорость поставки:
Team Topologies, как адаптивная модель проектирования организации, позволяющая организациям достигать скорости и стабильности.
Нам нужно полагаться на команды, которые могут эффективно входить в коллаборацию для баланса скорости и безопасности.
Авторы не пишут об адаптивности или гибкости. Возможно, вы считаете, что скорости вполне достаточно? Это заблуждение, высокая скорость не приводит автоматически к получению организацией гибкости. Я детально разбирал этот вопрос в статье “Продуктовые Титаники—как организации теряют гибкость”.
Один из распространенных мифов— то, что Agile означает быструю поставку (Крэйг Ларман)
Что же такое гибкость? Цитата от подписанта Аджайл Манифеста:
Гибкость – это способность организации адаптироваться под новые условия и менять направление, создавая при этом максимум ценности и клиентского опыта (Майкл Биддл).
Метафора для размышления. Титаник был одним из самых скоростных кораблей своего времени. За минуту до столкновения с айсбергом он двигался со скоростью 42.5 км/ч. Гигантская машина не смогла изменить направление движения. Это пример системы, оптимизированный под скорость. Гибким и адаптивным можно считать водный мотоцикл, который способен резко менять направление, уходить от препятствий, одновременно двигаясь с большой скоростью.
4 типа команд в Team Topologies
(Рис.1: типы команд в Team Topologies)
Авторы книги предлагают четыре типа команд для создания организации, оптимизирующей скорость поставки (Рис. 1):
- Stream-aligned team — узкоспециализированные кросс-функциональные команды, которые составляют большинство команд в организации (дается рекомендация в 80-90% от общей численности). Включает все необходимые компетенции discovery/ production/operation. Микс генералистов и узких специалистов.
- Complicated-subsystem team — компонентная команда с фокусом на сложной архитектурной системе (“математическая модель”, “видео кодек”, “движок распознавания лиц”). Команд такого типа должно быть немного. Они состоят из технических специалистов с навыками, которые тяжело найти на рынке или развить внутри организации.
- Enabling team — берет на себя задачу исследования и консультаций в области инструментов, практик, на которые нет времени у кросс-функциональных команд. Примеры миссий: построить deployment pipeline, создать базовый тестовый фреймворк. Часто обучает через сессии парного программирования, моб-программирования. Небольшая фултайм команда из специалистов технического или продуктового домена. НЕ навязывает свои решения, команда-слуга.
- Platform team — поддерживает автономность команд за счет разработки низкоуровневой части экосистемы, снижая их когнитивную нагрузку. Создает сервис самообслуживания (API, портал знаний, Wiki). Внутри может состоять из большого количества команд других типов. Получает регулярную обратную связь от команд по качеству своего обслуживания.
Complicated-subsystem team, Enabling team, Platform team имеют право на жизнь, сам принимал участие в формировании таких команд. По ним тоже есть вопросы, но основные претензии к stream-aligned team, поэтому давайте фокусироваться на этом типе команд в разборе.
Stream-aligned teams и Copy Paste Scrum
Team Topologies создают организационную структуру, состоящую из большого количества скоростных и узконаправленных команд, называемых stream-aligned teams. А еще этот подход нам знаком давным-давно под названием Copy Paste Scrum (Рис. 2) и он порождает побочные эффекты:
- Зависимости между командами и вынужденную координацию;
- Отсутствие сквозных приоритетов и работу над менее важным;
- Хрупкость и неспособность быстро адаптироваться под изменяющиеся тренды рынка;
(Рис. 2: Copy Paste Scrum)
С увеличением количества узкоспециализированных команд, продуктовая организация теряет способность реагировать на изменения рынка. Я называю этот эффект продуктовой фрагментацией (Рис. 3). Почему так происходит? Дело в том, что команды, долго работая в одном из доменов, не могут “подхватить” работу в других частях продукта, а это может понадобиться для снятия пиковых нагрузок, которые могут случиться из-за резкого изменения рынка.
(Рис. 3: продуктовая фрагментация)
Выводы
Team Topologies полезны организациям с исключительным фокусом на скорости поставки. Это возможно, если рынок стабилен, не ожидается резкого изменения спроса, а сам продукт — дойная корова с понятным и проверенным ценностным предложением.
Team Topologies не подойдут организациям с продуктами, которые находятся на высококонкурентном рынке, где необходимы быстрые и дешевые адаптации под меняющиеся условия бизнес-среды.
P.S. Если вам интересно, как же, все таки, оптимизировать вашу структуру под адаптивность и гибкость, добро пожаловать на наш тренинг Designing Agile Organizations (DAO).
