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

Перевод оригинальной статьи 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»

Повышаем гибкость с Feature Team Adoption Map (FTAM)

Перевод оригинальной статьи “Feature Team Adoption Map Explained” Сезарио Рамоса, которая появилась в нашем англоязычном блоге в сентябре 2018 года.

Когда заходит речь про внедрение LeSS, инструмент Feature Team Adoption Map (FTAM, «карта внедрения фиче-команд») часто используется как один из самых мощных инструментов. Это ценный инструмент, который можно использовать для различных целей.

Что это такое?

Мне не удалось найти официальное определение в литературе по LeSS, но, на мой взгляд, следующее определение хорошо отражает суть: «Feature Team Adoption Map — это визуальный график, отражающий способность команды поставить готовый продукт. Эта способность выражается как потенциальный объем работы для команды и степень кросс-функциональности команды».

Критерии Готовности (DoD) показывают возможности команды с точки зрения активностей, необходимых для поставки потенциально готового к релизу продукта, а это то же самое, что и степень кросс-функциональности команды. FTAM дополняет их знанием предметной сферы продукта, а это то же самое, что и степень кросс-компонентных возможностей команды. Другими словами, FTAM — это расширение DoD, добавляющее к этой концепции второе измерение: продукт.

Изображение FTAM, представленное ниже, взято из книги по LeSS.

Читать далее «Повышаем гибкость с Feature Team Adoption Map (FTAM)»

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

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

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

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

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

Мультикомандное уточнение Бэклога Продукта

Перевод оригинальной статьи Сезарио Рамоса «Multi-team Backlog Refinement»

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

Что такое Уточнение Бэклога Продукта?

Уточнение Бэклога Продукта (Product Backlog Refinement, PBR) — это мероприятие, которое регулярно проводят Скрам-команды, чтобы прояснить и уточнить Элементы Бэклога Продукта (Product Backlog Items, PBI), которые предстоит взять в работу в следующих Спринтах. В однокомандном Скраме команда обычно проводит одну или несколько подобных встреч за Спринт. 

Ниже приведены примеры связанных с этим событием активностей:

  • Понимание того, какую проблему надо решить: Владелец Продукта рассказывает несколько последовательных историй и связывает их с текущими бизнес-целями. Команда обсуждает “почему мы это делаем?”, “как понять, что мы решаем нужную проблему?”. Некоторые команды используют карту историй (story mapping), карту влияния (impact mapping), игры «Speedboat», «Я и моя тень» и технику «5 почему». 
  • Разбивка больших элементов для более простого обсуждения и изучения.
  • Оценка элементов.
  • Понимание потребностей клиента: команда обсуждает“Почему пользователь хочет этого?”, “Правильно ли мы решаем его проблему?”. Некоторые команды используют доску историй (storyboard)  до и после, карты Pain Gain.
  • Прояснение элементов: Некоторые команды используют технику спецификации на примерах (Specification By Example) и создают приемочные тесты для пользовательских историй, используют описание историй с помощью спецификаций языка Gherkin, таблицы потоков и/или таблицы решений.
  • Определение планов исследовательского тестирования: Выявление рисков при достижении цели, выявление фич, которые требуют ручного тестирования. Некоторые команды используют план исследовательского тестирования (Exploratory Test Charter) для каждой фичи и проводят сессии исследовательского тестирования всей командой.
  • Создание первоначального дизайна: Моделирование на магнитной доске, прототипы дизайна…

Читать далее «Мультикомандное уточнение Бэклога Продукта»

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

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

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

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

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

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

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

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

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

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

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