Как обучение в команде влияет организационную гибкость

Как связаны скорость и гибкость в Скраме

Чем быстрее Скрам-команда поставляет готовые элементы Бэклога Продукта (PBI) на рынок (Time 2 Market), тем быстрее получает обратную связь, и тем больше знаний о продукте, клиентах, рынке она приобретает. Опираясь на обратную связь, Владелец Продукта изменяет порядок элементов Бэклога Продукта, размещая самое ценное наверху. На системной диаграмме это выглядит так:

Что такое организационная гибкость (Agility)

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

Как обучение команды связано с гибкостью

Представьте себе Скрам-команду, которая работает над “мобильным банком”, который разрабатывается одновременно на двух платформах: Android и iOS. Представьте, что после первого релиза и получения обратной связи с рынка оказывается, что в ближайшие недели все усилия необходимо бросить на развитие именно iOS платформы. Упорядоченный Бэклог Продукта выглядит следующим образом:

У меня 2 вопроса к вам:

Что, скорее всего, произойдет в таком случае?
Какие действия рождаются исходя из долгосрочной перспективы и системного мышления?

В реальной жизни, и я был свидетелем многократно, желание утилизировать людей будет так давлеть, что Владелец Продукта изменит порядок Бэклога Продукта, чтобы занять Android разработчиков:

Скорее всего, Скрам-команда продолжит работать над неоптимизированным Бэклогом Продукта и не будет заниматься самым ценным для организации.

Системное решение — Android-разработчики помогают iOS-разработчикам (парное программирование, моббинг, swarming) и обучаются. Порядок Бэклога Продукта останется прежним. В долгосрочной перспективе такая команда становится более гибкой, потому что в ней будут работать люди, которые можут выполнять разные типы работ (multi-functioning специалисты). Идея мульти-обучения была заложена в основу Скрама еще в знаменитой статье 1986 года “The New New Product Development Game”. Это и есть Скрам-стиль работы, когда команда “накидывается” на самое ценное в Бэклоге Продукта. Гибкая команда, в которой разработчики помогают друг другу, имеет более низкий Time 2 Market по сравнению с командами узких специалистов. Давайте взглянем на системную диаграмму опять:

Обучение в Скрам-команде и приобретение новых компетенций напрямую влияет на ее гибкость, Time 2 Market и организационную гибкость.

Из Flash в Blackberry, из ActionScript 3.0 в Java

Много лет назад я работал Flash/Flex разработчиков в одной из украинских компаний в Днепропетровске. Затем сменил место работы и перешел в компанию Epam Systems. Туда должен был зайти новый “вкусный” для меня проект с Flex-разработкой. Но этого не случилось. У меня был выбор — опять сменить место работы или выучить новый язык программирования и присоединиться к другому проекту в компании. Я выбрал последнее, и мне пришлось перейти из Flex-разработки в разработку под Blackberry. Для этого за несколько недель пришлось выучить Java. Чуть позже я стал тимлидом одной из таких команд. Я просто сделал свой выбор и решил заняться самым ценным для компании Epam Systems, а не оставаться узким специалистом и ждать когда придет долгожданный проект на Flex.

Обучение в МТС Кассе

В приведенном примере с мобильным банком и Andoid и iOS-разрабчиками все просто. Настоящие же сложности начинаются в больших продуктах, где с одним Бэклогом Продукта работают несколько команд, иногда десятки команд. Тогда разрыв в знаниях становится просто колоссальным. Я помню, как в момент запуска продуктовой группы МТС Кассы, во всех четырех командах разработчики сразу почувствовали себя “недоутилизированными”. Позже на Ретроспективе первого Спринта вопрос “недоутилизации” набрал огромное количество голосов ребят и я, фасилитируя Ретроспективу, помог ребятам прийти к алгоритму, который должен был запускаться, когда у разработчика не было работы по основной специализации:

Учиться, помочь своей команде
Помочь другой команде
Взять задачу наперед

Как может Скрам-мастер помочь команде стать более гибкой

Вопрос обучения — один из самых острых в Скраме. Обучение поддерживает скорость, а скорость поддерживает создание бизнес-ценности. Вот несколько идей для Скрам-мастеров:

Создайте вместе со Скрам-командой системную диаграмму, на которой вы увидите связь между обучением, скоростью поставки, бизнес-ценностью и организационной гибкостью. Обсудите с командой, что это значит для вас.
Создайте с командой матрицу компетенций (“звездная карта”), которая отразит степень вашей гибкости. Обозначьте те компетенции, которые каждый из участников будет развивать. Где ваши узкие горлышки? Какие ваши риски? Что будете с этим делать?
Создайте с командой алгоритм, который будет запускать в том случае, если кто-то из команды “недоутилизирован” по своей ключевой специальности. Как вы будете учиться? Как будете помогать друг другу?

Основные идеи

Скорость поставки (Time 2 Market) напрямую влияет на объем обратной связи, получаемой с рынка и на количество решений по изменению порядка элементов Бэклога Продукта.
Организационная гибкость коррелируется с количеством решений по изменению порядка элементов Бэклога Продукта.
Обучение команды делает ее более гибкой со временем.
У гибкой команды, в которой участники помогают друг друга, более низкий Time 2 Market.
Обучение — важный навык доступный любому в команде. Люди могут учиться.
Скрам-мастер помогает Скрам-команде понять важность обучения для получения организационной гибкости.