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

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

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

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

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

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

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

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

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

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

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

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

Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)

Обзоры Спринта

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

  • Владелец Продукта открыл встречу и громко зачитал Цели Спринта, над которыми работала продуктовая группа. Затем Владелец Продукта перечислил элементы, которые уже были выполнены.
  • Команды по очереди кратко рассказали о сложностях, с которыми им пришлось столкнуться во время Спринта, и о том, как им удалось (или не удалось) их преодолеть.
  • Гостей пригласили посетить станции. Событие было организовано в формате «базара» или ее более структурированном варианте «выставка». На каждой станции у нас было по меньшей мере два разработчика. Один из них демонстрировал Инкремент и просил дать отзывы о нем, а другой просто все записывал.
  • После демонстрации мы вернулись к формату открытого обсуждения. Владелец Продукта рассказал о новостях рынка, изменил приоритеты элементов Бэклога Продукта и ответил на все вопросы.
  • Затем гости покинули помещение, а команды и Владелец Продукта собрали обратную связь по всем станциям и, когда это требовалось, обновили некоторые из артефактов — карту влияния (impact map), канвас ценностного предложения (value-proposition canvas), карту историй (story mapping) и, конечно, Бэклог Продукта.

Читать далее «Обзор Спринта и Ретроспектива (кейс МТС Касса 10-я часть)»

PBR в LeSS (кейс МТС Касса часть 9-я)

Уточнение Бэклога Продукта (PBR) в LeSS

В масштабируемом Скраме PBR становятся обязательным событием (а не активностью). Это происходит, потому что в крупных продуктовых группах PBI получаются очень большими и возникает необходимость в масштабном обучении и координации между командами. Появляется необходимость планировать минимальное количество встреч с клиентами и пользователями. В LeSS есть несколько вариантов проведения PBR (руководство «Типы Уточнений Бэклога Продукта»):

  • Общее Уточнение Бэклога Продукта с представителями команд, которое предполагает высокоуровневый анализ и видение, оценку и разбиение элементов (руководство «Общее Уточнение Бэклога Продукта»).
  • Мультикомандное Уточнение Бэклога Продукта. Несколько команд в одной комнате уточняют несколько PBI одновременно (предпочтительно) (руководство «Мультикомандное Уточнение Бэклога Продукта»).
  • Однокомандное Уточнение Бэклога Продукта. Проводится как в Скраме для одной команды.

Нет каких-либо особых правил по комбинированию PBR, однако LeSS рекомендует проводить мультикомандные PBR. Давайте остановимся на их подробнее. Читать далее «PBR в LeSS (кейс МТС Касса часть 9-я)»

Планирование в LeSS (кейс МТС Касса 8-я часть)

Первая часть Планирования Спринта

За час до Первой Части Планирования Спринта Владелец Продукта и двое бизнес-аналитиков вносили финальные изменения в Бэклог Продукта. Затем представители всех команд (обычно по два человека от команды) принимали участие в Первой части Планирования Спринта.

Агенда встречи. Мы обычно придерживались следующей агенды:

  • обновляем Бэклог Продукта (вернуть невыполненную работу в Бэклог Продукта и оцениваем объем оставшейся работы);
  • Владелец Продукта очередной раз кратко описывает основные моменты в Бэклоге Продукта и при необходимости поясняет отдельные детали элементов (это уже было на PBR);
  • повторно рассматриваем Критерии Готовности (DoD);
  • представители команд выбирают стикеры с PBI из верхней части столбца «Ready» и прикрепляют их на дорожки своих команд на доске;
  • находим возможности для совместной работы команд (зависимости) и визуализируем их на доске;
  • решаем, нужна ли мультикомандная Вторая часть Планирования Спринта (когда между командами есть зависимости);
  • определяем общую Цель Спринта для продуктовой группы и/или отдельные Цели Спринта для команд.

Читать далее «Планирование в LeSS (кейс МТС Касса 8-я часть)»

LeSS в MTC Кассе 7-я часть (первый Спринт, визуализация, координация)

Первый Спринт

Как говорят, «первый блин комом». Это относилось и к первому Спринту. Несмотря на всю подготовку и тренинги, команды лицом к лицу столкнулись со сложностями локальной оптимизации. Ранее в компании не было ориентированного на клиентов Бэклога Продукта. Теперь же порядок в Бэклоге Продукта определялся, главным образом, важностью фич для клиента.

Изучив Бэклог Продукта, дизайнеры и разработчики Android увидели, что в первом Спринте для них мало работы. Поэтому в ходе Спринта они много времени занимались обучением и помогали другим. Это обычная ситуация: первый Спринт выявляет так называемый «долг знаний», который всегда скрыто присутствует в функциональных подразделениях. Особенно это касается масштабных внедрений, когда речь идёт о крупных подразделениях — и крупных «долгах знаний». Этот новый «организационный перенос навыков» (если использовать формулировки из первой статьи о Скраме в Harvard Business Review за 1986 год) был очень непривычен участникам группы. Люди не понимали, почему нужно учиться вместо того, чтобы «делать что-то полезное».

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

LeSS в MTC Кассе 6-я часть (Initial PBR)

Initial PBR

Видение Продукта и бизнес-модель. Очень полезно корректировать понимание продукта разработчиками — не только на уровне общего видения, но и с более глубоким погружением в бизнес-модель. Продуктовая группа в LeSS — это часть более широкой организационной среды, включающей маркетинг, продажи, нормативно-правовое соответствие, юридическую поддержку и т. д. Поэтому мы начали Первоначальное Уточнение Бэклога Продукта с того, что команды создали канвасы бизнес-моделей, а затем объединили их в один. Мы последовательно обсуждали все аспекты бизнес-модели, а Владелец Продукта нас поправлял.

Попробуйте воркшоп по разбиению задач

Типичная проблема: команды не могут разбить PBI на более мелкие элементы. Задача становится еще важнее, если есть фиче-команды, потому что нам надо снизить вариативность в более мелких наборах фич и таким образом уменьшить общую длительность цикла. Мы предложили командам воркшоп по разбиению задач, в котором участвовали все команды.

Я раздал листы с шаблонами и примерами разбиения элементов (эксперимент «Попробуйте разбить на части элементы Бэклога Продукта). Затем я установил таймер на 10 минут и попросил участников изучить их. Самый эффективный способ усвоить материал — это объяснить его другим людям. Поэтому через 10 минут я попросил участников объединиться в пары и в течение следующих 10 минут объяснить друг другу прочитанное. Затем Владелец Продукта выбрал крупный элемент из Бэклога Продукта. Люди разделились на небольшие смешанные группы и начали разбивать этот элемент на части.

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

Попробуйте оценочную и корреляционную сетку.

Когда над одним Бэклогом Продукта работает несколько команд, необходимо синхронизировать оценки. Пилотная фиче-команда уже имела опыт оценивания в относительных величинах и имела много готовых элементов Бэклога Продукта. Мы сформировали оценочную сетку, где отобразили готовые элементы как образец для сравнения. Затем провели воркшоп, на котором пилотная фиче-команда объяснила остальным разработчикам эталонные PBI и помогла им скорректировать стори-поинты.

Фасилитация первого мультикомандного Уточнения Бэклога Продукта (PBR). Ранее команды по внедрению LeSS получали спецификации от выделенной аналитической группы. Теперь они должны были самостоятельно уточнять детали по каждому элементу. Мы пригласили в комнату экспертов в предметных областях. Команды разбились на четыре смешанные группы и начали работу на станциях, каждая у своей стены. На каждой станции эксперт помогал участникам прояснить детали PBI. Через 25 минут все переместились по часовой стрелке на следующую станцию (кроме экспертов). На каждом флипчарте уже были заметки, диаграммы и объяснения, оставленные предыдущей группой, что очень помогло вникнуть в тему. Так командам понадобилось чуть больше часа, чтобы прояснить три PBI. После перерыва мы ещё раз повторили процесс.

LeSS в МТС Кассе 5-я часть (выборы Скрам-мастеров и запуск сообществ)

Выбор Скрам-мастеров

Скрам-мастер в LeSS — это выделенная роль на полный рабочий день, предполагающая работу с 1–3 командами. Мы хотели нанять опытного Скрам-мастера до того, как изменим организационную структуру. К сожалению, у нас не получилось. Поэтому я в итоге решил стать вторым Скрам-мастером, пока мы не найдем замену.

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

Запуск сообществ

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

Некоторые из них начали работу уже через несколько дней, остальные — в ходе первых двух Спринтов. Мы убедились, что Скрам-мастер помог им определить:

  • цель сообщества;
  • рабочие договорённости.

Разработчики также регулярно встречались и с удовольствием участвовали в работе сообществ. Я помню встречу, посвященную автоматизированному тестированию, которая проводилась с применением моб-программирования. Одна девушка-дизайнер тоже приняла участие, потому что хотела начать изучать автоматизацию. Люди хотели учиться!

LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)

Попробуйте организовать Lean Coffee!

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

Выбор Владельца Продукта

Кандидатурой на роль Владельца Продукта, естественно, оказался Технический директор, так как он один из основателей компании и знает рынок, бизнес и клиентов лучше, чем кто-либо ещё. Выбор был настолько очевиден, что я не ожидал никаких подвохов, однако они появились через несколько месяцев. Читать далее «LeSS в МТС Кассе 5-я часть (от Lean Coffee до DoD)»

LeSS в МТС Кассе 4-я часть (обучение LeSS)

Дальнейшие шаги по внедрению LeSS

Летом 2017 года я посетил в Милане мастер-класс Крэга Лармана по LeSS. Одна из самых запомнившихся рекомендаций звучала так: «Думай как политик, а не как инженер». Хотя Владелец Продукта подталкивал меня внедрить LeSS как можно быстрее, совет Крэга помог мне притормозить внедрение. После успеха пилотной фиче-команды я увидел, что уровень доверия со стороны менеджмента вырос. К тому времени мы получили полную поддержку от руководства компании. Круто! С другой стороны, я понял, что многие разработчики из компонентных команд скептически относились к идее LeSS. Мы решили обучить их, чтобы перемены в компании были добровольными, а не вынужденными (руководство «Три принципа внедрения»).

Бэклог трансформации

В группу по трансформации компании вошли Владелец Продукта, несколько добровольцев из группы производства, Скрам-мастер пилотного проекта и я сам. Вот как выглядели некоторые задачи:

  • провести сертифицированный тренинг по основам LeSS (Certified LeSS Basics, CLB);
  • провести несколько семинаров в формате Lean Coffee для ответов на частые вопросы по LeSS;
  • создать первоначальный Бэклог Продукта;
  • создать HitMap;
  • организовать мастер-класс по самостоятельному формированию команд;
  • сформулировать цель для совершенствования;
  • выбрать Скрам-мастеров в командах;
  • разработать Критерии Готовности (DoD);
  • запустить работу сообществ и найти компонентных менторов;
  • провести первоначальное Уточнение Бэклога Продукта (PBR).

Если вспомнить, то мы потратили полтора месяца, чтобы подготовить изменения и создать подходящую для внедрения LeSS организационную структуру. Читать далее «LeSS в МТС Кассе 4-я часть (обучение LeSS)»