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-я часть)»

Учимся работать с семью командами (МТС Касса 11-я часть)

Я очень удивился, когда узнал, что компании «МТС» и «LiteBox» еще в 2017 договорились году увеличить количество команд до семи. Таким образом, сразу после изменения структуры к продуктовой группе стали присоединяться новые команды.

Команда RITG со стороны аутсорсинговой компании-партнера. Владелец Продукта был полон энтузиазма по поводу присоединения новых команд и заключил партнерство с одной из аутсорсинговых компаний в своем городе. Через несколько недель новая команда под названием RITG присоединилась к продуктовой группе. В течение нескольких Спринтов мы пытались интегрировать людей в наш процесс. Мы постоянно испытывали проблемы коммуникации во время Уточнений Бэклога Продукта (PBR). Кроме того, они не показывались на Обзоре Спринта. Тогда я порекомендовал переместить их в офис физически. Осуществить это было нелегко, однако, несмотря на все, Владелец Продукта добился успеха. С того момента у нас было пять команд в одном офисе.

Команда ROST в офисе. Тем временем, внутренний отдел по управлению персоналом помог нам создать еще одну фиче-команду под названием ROST. Два члена бывшей пилотной фиче-команды подключились к ней на несколько Спринтов, чтобы присоединение прошло максимально гладко.

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

К сожалению, новые посредники. Ранее я говорил, что одним из основных препятствий при внедрении было привлечение людей, которые не поддерживали изменения и вели себя как посредники между командами и клиентами. Количество команд росло, и группа бизнес-анализа также росла. Был нанят новый бизнес-аналитик, который фокусировался на внешних активностях. Вот как выглядела структура в тот момент:

Читать далее «Учимся работать с семью командами (МТС Касса 11-я часть)»

HR-практики в Скрам и LeSS

В этой статье вы найдете информацию о важности HR-практик в LeSS, а также список экспериментов  из книги “Agile Development: Thinking and Organizational for Large-Scale Scrum”, которые вы можете использовать.

Почему HR-практики важны в Скраме и LeSS.

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

Модель Джея Гилбрайта “Star Model” говорит о том, что стратегия, структура, процессы, награды и HR-практики в организации должны находиться в балансе и подкреплять друг друга. Иначе создается напряжение. К примеру, текущая функциональная организационная структура может мешать компании достигать таких стратегических целей, как гибкость.

Читать далее «HR-практики в Скрам и LeSS»