Большой Голландский Банк | Наш путь к масштабируемой гибкости

Авторы:

Cезарио Рамос, г-н А, г-жа Б и г-н В

ПО ПРИЧИНАМ ПРАВОВОГО ХАРАКТЕРА Я НЕ МОГУ НАЗВАТЬ РЕАЛЬНЫХ ИМЕН КОМПАНИЙ И УЧАСТНИКОВ

Введение

В этой статье мы расскажем о том, как мы улучшили модель на базе Spotify в трайбе Голландского Банка.

Над нашим продуктом кредитования бизнеса работают более 20 команд.

Мы разрабатываем наш продукт в трех локациях со смешанными командами. Участники каждой из команд владеют навыками бизнеса, ИТ и операционными навыками. При такой схеме работы мы поставляем нашим клиентам ценный продукт каждые две недели. Мы достигли этого, помимо прочего, благодаря внедрению принципов LeSS для оптимизации нашего способа работы в стиле Spotify.

Итак, что мы изменили?

В этой статье мы расскажем нашу историю с четырех различных точек зрения.

С точки зрения:

  • лидера трайба,
  • консультанта,
  • главы ИТ-отдела,
  • Владельца Продукта для части продукта, связанной со всеми циклами взаимодействия с клиентом. 
Читать далее «Большой Голландский Банк | Наш путь к масштабируемой гибкости»

Где можно услышать «реальные примеры» и истории внедрения Скрама

Ответ на это вопрос неожиданно пришёл к нам вчера после очередного тренинга.

Интересный паттерн заметили — в ожиданиях и обратной связи тренерам больше всего стикеров звучат так «Больше практических кейсов», «реальные примеры», «больше историй про факапы при внедрении Скрама», «конкретные компании, где Скрам работает»…

И каждый раз мы это покупаем (сами обожаем кейсы!) и хотим рассказать все их разом 🙂 Но в рамках тренинга, где есть учебные задачи и всего 16 часов на погружение в Скрам, так сложно найти место подробным структурированным рассказам «а как оно, в настоящей жизни?». Мы делимся небольшими зарисовками, отдельными событиями и эпизодами, не более.

И тут мы осознали, что конференция LeSS Day Europe — это же и есть площадка реальных «живых» кейсов, со всеми успехами и “факапами”. И даже лучше, чем тренинг, потому что:

— Кейсы рассказывают CEO компаний, менеджеры, Владельцы Продуктов, Скрам-мастера — те, кто своими руками проводил изменения.

— Доклады только про реальный опыт перехода масштабируемому Скраму (LeSS).

— Нет учебных целей, а есть свободное пространство для знакомств и общения.

— Стоимость в 10-20 (!) раз дешевле, чем тренинг 🙂

Так что, реальные кейсы, “факапы”, истории из первых уст — 6 декабря с 9:30 до 19:00 на конференции LeSS Day Europe.

Программа тут 

Увидимся!

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

ING our journey towards scaled agile

На конференции 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 (Аджайл-коуч).

ING Org Structure
Читать далее «ING совершенствует модель Spotify с помощью LeSS»

Фасилитация Overall Retro

Если вы уже знакомы с  масштабируемым Скрамом (LeSS), то для вас не секрет, что Общая Ретроспектива обеспечивает работу эмпирического контроля на уровне всей системы (продуктовой группы и организации). Мы инспектируем взаимоотношения, инструменты и процессы на уровне системы. На Ретроспективе присутствуют представители от команд, Владелец Продукта, менеджеры и Скрам-мастера, которым нужно основательно подготовиться. Эта статья поможет вам провести Общую Ретроспективу позитивно и продуктивно! 

Читать далее «Фасилитация Overall Retro»

Владелец Продукта в больших организациях

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

Скачать брошюру

Владелец Продукта в небольшой компании

Руководство по Скраму описывает контекст небольшой компании или стартапа. В этом случае все просто: 7-9 человек обладают всеми необходимыми навыками и выполняют всю работу. Владелец Продукта определяет видение и порядок Бэклога Продукта, а Команда Разработка хорошо понимает бизнес и проблемы своих клиентов, уточняя требования напрямую с ними. Маленькая организация — это отсутствие бюрократии, передач и минимум потерь. Скрам изначально был создан и успешно зарекомендовал себя в работе с небольшими командами. 

Читать далее «Владелец Продукта в больших организациях»

Эффективный PBR часть I

В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.

Почему PBR важен

PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.

Разработчики общаются с клиентами напрямую

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

  • промежуточные артефакты (BRD, спецификации и т.д.);
  • многочисленные передачи, как результат, искажение и потеря информации;
  • низкая скорость принятия решений;
  • отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
  • непонимание разработчиками бизнес-домена.

Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки. 

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

В масштабируемом Скраме команды выясняют детали требований напрямую со стейкхолдерами. Владелец Продукта оставляет за собой упорядочивание Бэклога Продукта.

Читать далее «Эффективный PBR часть I»

Market of Skills на большом масштабе

Как познакомить большое количество людей

В статье делюсь с вами эпизодом запуска большой продуктовой группы. Стояла задача быстро познакомить 70+ разработчиков, а затем сформировать фиче-команды, работающие над одним продуктом.

Market of Skills

Market of Skills — активность, помогающая лучше узнать друг друга. Она часто открывает слепые зоны, о которых люди не догадываются. Идея проста — у каждого есть персональное место на “базаре”, на котором продаем себя, навыки и таланты, а также покупаем их у коллег.

Раздав листы флип-чартов, я попросил изобразить на них:

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

Из-за большого размера группы базар был разделен на 3 раунда. В первом раунде (15 мин) торговали только первые номера, а остальные выступали в роли покупателей, во втором раунде вторые и т.д. Покупатели получили базарную валюту — стикеры и наклейки. На стикерах можно писать:

  • Навыки, которые хочется приобрести.
  • Навыки, о которых продавец забыл.
  • Навыки, которые хочется продать.

Раз, два, три… Поехали! По сигналу колокольчика базар стартовал. И он был настоящим!

Продавцы зазывали покупателей и продавали себя. Небольшое помещение наполнилось гулом десятков голосов. Повсюду были улыбки и смех. Я снял шапку фасилитатора на некоторое время и отправился на прогулку по базару, знакомясь с людьми и раздавая наклейки. С каждым раундом уровень энергии возрастал. И мне жалко было закрывать последний раунд, ведь это было так здорово!

Проводя Ретроспективу дня, ребята отметили, что Market of Skills была одной из самых ценных активностей за день.

Основные мысли статьи

  • Market of Skills помогает людям узнать друг друга.
  • Market of Skills очень полезна для старта большой продуктовой группы.
  • Проводите базар в несколько раундов, если у вас много участников.
  • Стимулируйте людей зазывать покупателей и “продавать” себя.

Не давайте ответ, не услышав вопрос

Перевод оригинальной статьи Ceзарио Рамоса Do not provide the answer before knowing the question

Я общался с компанией, которая внедряла модель Spotify и попросила меня помочь. Они хотели понять, в чем разница между моделью Spotify и LeSS. Сначала мы обсудили, что такое LeSS. Я объяснил, что LeSS — это организационный дизайн, оптимизационные цели которого скорость, адаптивность и обучение. LeSS для организации то же самое, что Скрам для одной команды.

С этого ответа началась интересная дискуссия о различиях между двумя моделями. Я не эксперт по Spotify, но видел достаточно внедрении этой модели, чтобы вести интересную дискуссию. Ниже я кратко опишу три основных момента из нашего обсуждения:

HR

Возможное отличие версии Spotify, которую внедряла эта команда, от LeSS заключалась в том, что у них есть руководитель («лид») чаптера («отдела»), который отвечает за кадровый состав чаптера. Например, у них может быть центр передового опыта — чаптер Тестирования, и в этом чаптере лид отвечает за тестировщиков. Это монофункциональный организационный элемент. В LeSS мы стараемся избегать таких структур. Напротив, нам больше нравятся кросс-функциональные менеджеры, которые отвечают за состав кросс-функциональных команд. Это способствует мультифункциональному обучению и, как следствие, повышает гибкость организации.

Непрерывное улучшение

Ещё одно отличие заключается в том, что LeSS базируется на принципе Эмпирического Контроля Процессов, тут нет модели, которую можно бы было скопировать. Копирование модели других организаций опасно, так как контексты отличаются, и очень вероятно, что скопированная модель не обеспечивает те же преимущества в другом контексте. Основная ценность заключается не в копировании модели как таковой, а в самом процессе выработки такой модели, которая будет работать именно для вас, и в обучении, сопутствующем этому процессу.

Но ещё хуже то, что копирование модели не даёт ощущения, что эта модель — ваша. Почувствовать, что у вас есть собственная модель, получается только тогда, когда вы создаете что-то самостоятельно. И если члены вашей команды чувствуют, что обладают чем-то, то выше вероятность, что они сами будут стремиться это улучшать. А это главное условие непрерывного совершенствования. Сложно почувствовать это, просто копируя чужие действия. Это скорее, как взять в долг — совсем не то же самое, как создать самостоятельно. Я отношусь к машинам из проката совсем не так, как к своим собственным.

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

Компания понимает этот момент, они очень серьёзно относятся к непрерывному улучшению.

Становление модели

Получается, что внедрять модель в качестве конечного решения без учета особенностей конкретной организации — это как отвечать, не узнав вопрос. На мой взгляд, это глупо. Не делайте так. Вместо этого вы можете начать с самого простого процесса, который будет работать. А потом вы выстроите свою модель с помощью Эмпирического Контроля Процессов и фреймворка, который поможет всем чётко увидеть, что надо улучшать. Этот фреймворк называется Скрам. Как мы любим говорить, лучше создать свой метод, чем пытаться подогнать под себя чужой. Вы добавляете что-то только тогда, когда ваша команда видит в этом необходимость.

Насколько я понял, в этой компании они делают именно так. И весьма успешно.

Cезарио Рамос

Сезарио занимается широкомасштабными Аджайл-трансформациями по всему миру. Автор книг «Emergent» и «Scrum Patterns». Он также является сертифицированным тренером LeSS, профессиональным тренером по Скраму (Professional Scrum Trainer™) и сертифицированным коучем.

Мы не верим стикерам! Или как аналитики Рук поставили под сомнение результаты Воркшопа по Продукту

Кто мы и чего хотели

Мы — команда Рук (https://hands.ru), — пришли к необходимости сформировать SCRUM-команду для работы с продуктовым бэклогом. Для этого мы попросили Илью Павличенко и Рому Дорошенко провести у нас воркшоп по продукту, на котором мы разбирались, на какие компоненты можно разложить задачи из бэклога и какие компетенции потребуются в SCRUM-команде.

Табличка компонент бэклога

Так выглядят таблицы компонент (HitMap) и компетенций (FTAM), выработанные за время воркшопа:

Таблицы вызывали некоторое недоверие: они очень большие и оттого “непрозрачные”. Чтобы получить какое-то понимание, мы решили покрутить таблицу компонент и посмотреть, что и как поменяется. Имели в виду при этом такие соображения: Читать далее «Мы не верим стикерам! Или как аналитики Рук поставили под сомнение результаты Воркшопа по Продукту»

Извлеченные уроки и результирующие эксперименты (кейс МТС Касса 12-я часть)

В этой статье я описал некоторые эксперименты (Попробуйте… Избегайте…), которые помогли нам значительно приблизиться к сценарию успеха. К этим экспериментам я пришел после того, как провел ретроспективу всего процесса внедрения LeSS. Можете рассматривать их как уроки, которые я извлек.

Избегайте участия скептиков

В организациях с типичной иерархической функциональной структурой люди работают, как шестеренки механизма, и выполняют лишь одну конкретную функцию. Но у людей есть способность к самообучению, и они могут становиться более гибкими при командной структуре организации (руководство «Создание организаций с командной структурой»). Непосредственно перед тем, как изменить структуру команд, я заметил, что некоторые люди явно недовольны тем фактом, что компания станет организацией с командной структурой. На самом деле они хотели быть узкими узкими специалистами и откровенно противились Скраму — это было очень заметно. Они не скрывали своих настроений и были весьма прямолинейны. Честно говоря, я хотел внедрить LeSS как можно скорее, и сейчас понимаю, что это было огромной ошибкой. Вы даже не представляете, сколько помех и проблем может создать пара человек, если они по-настоящему против предстоящих изменений. Здесь вы можете посмотреть полезное видео, в котором доктор Коттер говорит о таком сопротивлении, и его совет сводится к следующему:

«Не дайте им встать на вашем пути, какими бы ни были ваши взаимоотношения, так как если вы позволите им остаться, они нанесут столько вреда, что ваши изменения потерпят крах». Читать далее «Извлеченные уроки и результирующие эксперименты (кейс МТС Касса 12-я часть)»