- Опубликовано РОУЭНОМ БАННИНГОМ
На конференции LeSS в 2019 году Cезарио Рамос начал доклад с заявления:
«Мы усовершенствовали модель Spotify, принятую ING»
С этого момента важность презентации стала понятна многим организациям, использующим схему работы «Squads, Tribes, Chapters and Guilds (Отряды, кланы, отделы и гильдии)», скопированной у компании Spotify. Многие называют эту схему «Моделью Spotify», несмотря на то, что многочисленные Аджайл-коучи, работавшие в Spotify, годами писали и говорили на конференциях о том, что Модели Spotify не существует, и что эту схему работы не следует копировать. Поэтому в настоящей статье мы будем называть эту схему «так называемой моделью Spotify».
Важная роль группы компаний ING (Нидерланды)
Особенно примечателен тот факт, что группа компаний ING из Нидерландов позволила этой схеме развиться от так называемой модели Spotify до LeSS. Многие случаи ее внедрения в других организациях были мотивированны именно примером ее использования в ING, чему способствовали консультанты из McKinsey & Company.
Помимо Cезарио, тренера по LeSS, над презентацией работали три менеджера: Надин, Ханс и Йорис из группы кредитования бизнеса в ING (в Бельгии и Нидерландах). Их место в организационной диаграмме видно на слайде ниже. Эта диаграмма структуры также включает в себя своего рода команду кросс-функционального руководства с довольно необычной аббревиатурой POCLAC, которая включает в себя: PO = Product Owner (Владельца продукта), CL = Chapter Lead (лид чаптера) и AC = Agile Coach (Аджайл-коуч).
Определение продукта
Чтобы выработать определение «продукта», на котором следует фокусироваться при использовании LeSS, сотрудники компании ING изучили портфолио фич за последние 6 месяцев и будущие 6 месяцев. Затем они проанализировали, какие команды будут «затронуты» при разработке этих фич, и создали визуализацию их вклада в эти фичи в процентном соотношении. В результате стало понятно, что из 24 команд 7–9 будут вовлечены в эту работу гораздо в большей степени, чем остальные. Поэтому было решено начать внедрение схемы LeSS с использования ее для этих 7–9 команд.
На этом рисунке показана Тепловая схема компонентов (Heat Map), которая использовалась для выявления команд, на которых следует сосредоточиться. Эта методика описана в блоге AgiliX в статье Определение продукта для внедрения LeSS.
Структура команд
Изучив некоторые теоретические материалы по LeSS, команды-участники провели воркшоп по самоорганизации команд. Обычно при внедрении LeSS предпочтение отдается созданию команд, территориально расположенных в одном месте, но в данном случае было необходимо, чтобы сотрудники из Бельгии были в курсе того, чем занимаются сотрудники из Нидерландов, поэтому было создано семь географически распределенных команд.
Владельцы продукта
Изначально, во время использования так называемой модели Spotify, в каждой команде ING был свой Владелец Продукта с фокусом на своей команде. В LeSS же, напротив, Владелец Продукта сосредоточен на продукте и работает с многими командами, количество которых может достигать восьми. Для семи команд, вовлеченных во внедрение LeSS, это означало, что шесть Владельцев Продукта потеряют свою роль. Многим организациям бывает сложно осуществить такой переход без негативной реакции со стороны людей, которые осознали, что их статус снизится.
Однако в данном случае, как ни странно, Владельцы Продуктов команд сами предложили освободить их от этой роли. Они пришли к этому решению после анализа портфолио задач, над которыми работают их команды, и осознания того факта, что значительная часть этих задач не имеет высокого приоритета для компании. Вероятнее всего, задачи низкого приоритета выполнялись потому, что для них выделялись команды с фиксированной миссией. После осознания этого факта шесть прежних Владельцев Продукта предложили освободить их от этой роли.
Чтобы узнать больше о преимуществах настоящих Владельцев Продуктов в модели LeSS, смотрите видео Майкла Джеймса ‘Why “Scrum” Isn’t Making Your Organization Agile: Harmful Misconceptions About Product Owner Role’ («Почему Скрам не делает вашу организацию работающей по Аджайл: опасные заблуждения по поводу роли Владельца Продукта»).
Кросс-компонентные кросс-функциональные фиче-команды
Важным фактором повышения адаптивности в ING стало наличие фиче-команд, которые работают над несколькими компонентами и несколькими типами фич для получения наивысшей ценности для клиента в каждом Спринте. Для этого необходимы тщательное изучение технологических компонентов и растущая вовлеченность команд в общее видение продукта и контекст клиента. В ING такая работа ведется постоянно.
Показатели
Компания ING использовала три KPI для усовершенствования схемы работы, а именно:
- высокую концентрацию на ценности для клиента в каждом Бэклоге Продукта и ускоренное завершение задач Epic;
- поставку ценностей в каждом Спринте с помощью кросс-функциональных команд;
- удовлетворенность и повышение навыков участников команд.
Следующий слайд показывает эффективность достижения этих KPI.
Обзор Спринта критичен для получения полной картины
Докладчики подчеркнули важность регулярного пересмотра видения продукта для синхронизации и формирования общего контекста для участников команды. Группа команд, созданная в ING, обсуждала видение продукта во время каждого Обзора Спринта. Владелец Продукта Йорис Верхейдж подчеркнул, что частый и регулярный пересмотр видения продукта был необходим, чтобы помочь командам начать мыслить за пределами «своей части» общего продукта, а также повысить внутреннюю мотивацию и общее понимание ситуации. В Обзорах Спринтов во время внедрения LeSS в группе кредитования бизнеса компании ING принимали участие около 80 человек из Бельгии, Индии и Нидерландов.
Прочие составляющие успеха в ING
Менеджеры из ING, проводившие презентацию, отметили, насколько мотивирующим и полезным для поставки ценности клиентам было создание у команд единого видения продукта и бэклога.
Кроме того, они подчеркнули особую важность принципа: «Позвольте командам решать проблемы, а не выполнять работу». Отношение к участникам команды как к людям, решающим проблемы, значительно контрастирует с распространенным подходом, когда разработчики программного обеспечения рассматриваются как многофункциональные исполнители заказов на «поставку» того, что решили за них другие.
«Вклад в непрерывную интеграцию ― ключ к масштабированию», гласит один из принципов методики, которой стараются придерживаться в ING.
На слайдах выше и ниже можно прочитать и другие полезные выводы.
Заключение
Организации, внедрившие “так называемую модель Spotify”, вероятно, выявили проблему нового рода для команд с относительно жесткой миссией и работающих над «частями» целого продукта. В каждый момент времени большинство таких команд с высокой вероятностью работает над задачами, которые не относятся к высокоприоритетным для компании. Для повышения итоговой ценности, поставляемой клиентам, им было бы полезно последовать примеру компании ING в Нидерландах и Бельгии, которая объединила Бэклоги нескольких команд в один Бэклог для общего клиентоориентированного продукта, что, в свою очередь, позволило перемещать приоритеты между командами от Спринта к Спринту. Такие действия могут вызвать и ряд сложностей, например, устранение большинства ролей Владельца Продукта и переход команд от мышления в пределах своей «части» продукта к более широкому видению.
