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

27 нояб. 2018 г. 4 min read

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

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

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