Много лет работая с командами, замечаю, как для Скрам-команд совсем не очевидна связь между организационной гибкостью и обучением. В этой статье мы проведем причинно-следственные связи, используя язык системных диаграмм.
Как связаны скорость и гибкость в Скраме
Чем быстрее Скрам-команда поставляет готовые элементы Бэклога Продукта (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.
- Обучение — важный навык доступный любому в команде. Люди могут учиться.
- Скрам-мастер помогает Скрам-команде понять важность обучения для получения организационной гибкости.
