ING совершенствует модель Spotify с помощью LeSS

На конференции LeSS в 2019 году Cезарио Рамос начал доклад с заявления:

С этого момента важность презентации стала понятна многим организациям, использующим схему работы «Squads, Tribes, Chapters and Guilds (Отряды, кланы, отделы и гильдии)», скопированной у компании Spotify. Многие называют эту схему «Моделью Spotify», несмотря на то, что многочисленные Аджайл-коучи, работавшие в Spotify, годами писали и говорили на конференциях о том, что Модели Spotify не существует, и что эту схему работы не следует копировать. Поэтому в настоящей статье мы будем называть эту схему «так называемой моделью Spotify».

Особенно примечателен тот факт, что группа компаний 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 для усовершенствования схемы работы, а именно:

Следующий слайд показывает эффективность достижения этих KPI.

Докладчики подчеркнули важность регулярного пересмотра видения продукта для синхронизации и формирования общего контекста для участников команды. Группа команд, созданная в ING, обсуждала видение продукта во время каждого Обзора Спринта. Владелец Продукта Йорис Верхейдж подчеркнул, что частый и регулярный пересмотр видения продукта был необходим, чтобы помочь командам начать мыслить за пределами «своей части» общего продукта, а также повысить внутреннюю мотивацию и общее понимание ситуации. В Обзорах Спринтов во время внедрения LeSS в группе кредитования бизнеса компании ING принимали участие около 80 человек из Бельгии, Индии и Нидерландов.

Менеджеры из ING, проводившие презентацию, отметили, насколько мотивирующим и полезным для поставки ценности клиентам было создание у команд единого видения продукта и бэклога.

Кроме того, они подчеркнули особую важность принципа: «Позвольте командам решать проблемы, а не выполнять работу». Отношение к участникам команды как к людям, решающим проблемы, значительно контрастирует с распространенным подходом, когда разработчики программного обеспечения рассматриваются как многофункциональные исполнители заказов на «поставку» того, что решили за них другие.

«Вклад в непрерывную интеграцию ― ключ к масштабированию», гласит один из принципов методики, которой стараются придерживаться в ING.

На слайдах выше и ниже можно прочитать и другие полезные выводы.

Организации, внедрившие “так называемую модель Spotify”, вероятно, выявили проблему нового рода для команд с относительно жесткой миссией и работающих над «частями» целого продукта. В каждый момент времени большинство таких команд с высокой вероятностью работает над задачами, которые не относятся к высокоприоритетным для компании. Для повышения итоговой ценности, поставляемой клиентам, им было бы полезно последовать примеру компании ING в Нидерландах и Бельгии, которая объединила Бэклоги нескольких команд в один Бэклог для общего клиентоориентированного продукта, что, в свою очередь, позволило перемещать приоритеты между командами от Спринта к Спринту. Такие действия могут вызвать и ряд сложностей, например, устранение большинства ролей Владельца Продукта и переход команд от мышления в пределах своей «части» продукта к более широкому видению.