Ретроспектива: отдых, работа или наказание?

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

А еще он мне рассказал про простую метафорическую модель, которой теперь делюсь с вами. 

Кто приходит на ретроспективу?

Согласно модели, условно бывает 4 типа участников ретроспективы:
— Исследователь
— Отпускник
— Покупатель
— Заключённый

Читать далее «Ретроспектива: отдых, работа или наказание?»

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

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

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

Plus que jamais или первый диалог с создателем освобождающих структур.

— Plus que jamais?
— Pardon?..
— Do you know what does it mean? I’m Henry, I’m French.
— Hi, Henry! (Понимаю, что речь про надпись на моей футболке). It means more than ever, it’s very about Liberating structures… Wait a minute… Henry?! Henry Lipmanowicz?


Хочу рассказать про Генри Липмановича (Henry Lipmanowicz). Он и Кейт МакКэнделс (Keith McCandless) создали освобождающие структуры — готовые шаблоны для фасилитации. Я люблю пробовать новые инструменты, технологии, подходы. И мне особенно интересно узнать о людях, которые их создают и развивают. Зачем им это? Это прибыльная бизнес-модель или этап личного развития? А вы когда-нибудь задумывались, зачем Кен Швабер и Джефф Сазерленд создали Скрам.

Читать далее «Plus que jamais или первый диалог с создателем освобождающих структур.»

Меняйте систему, а не людей

Система определяет результаты

Часто я демонстрирую картинку, где изображен организационный дизайн одной из продуктовых групп. Посмотрите на схему. Что вы замечаете?

  • Работа организована вокруг компонентных команд: аналитика, бэкенд, Android, Windows и т.д. 
  • Команды из-за многочисленных зависимостей передают из Спринта в Спринт проделанную работу. 
  • Цепочку замыкает “релиз менеджер”, который большой пачкой выводит новую функциональность на продакшн конечным пользователям. 
  • Легко заметить, что время цикла lead time или time-2-market равно нескольким Спринтам (2-3 месяца).

Мы называем это Copy Paste Scrum — использование Скрама в текущей организационной структуре без ее изменения. Какие факторы влияют на производительность всей системы? Обычно я задаю этот вопрос студентам, а затем даю несколько минут на генерацию факторов. Прошу разместить их в две колонки: система и люди. Типичный результат который получается в итоге:

Я проводил этот эксперимент с топ-менеджерами, разработчиками, менеджерами среднего звена, сотрудниками отдела продаж, маркетологами, но результат предсказуемый. Большинство стикеров оказываются в колонке “система”. Почему?

95% производительности зависит от системы (Эдвард Деминг 1982). 

Читать далее «Меняйте систему, а не людей»

Технические навыки

В этом посте размещен перевод статьи Рона Джеффриса о технических навыках, необходимых для команд, практикующих гибкую разработку.

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

Вот, кстати, несколько полезных статей на эту тему:

Читать далее «Технические навыки»

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

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

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

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

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

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

Прокачайте PBR при помощи Example Mapping

В этой статье мы поделимся с вами техникой Example Mapping для командной работы над спецификациями. Мы применили эту технику на Актуализации Бэклога Продукта (PBR) с продуктовой группой LeSS. Попробуйте и вы!

Об Example Mapping мы узнали из блога Мэтта Вина — автора тестового фреймворка Cucumber. Хотим отметить очевидные плюсы техники:

  • добавляет структуру в обсуждение элементов Бэклога Продукта; 
  • помогает найти пробелы в знаниях;
  • позволяет создать первоначальную версию приёмочных тестов сразу на PBR.

Мы уже писали о важности эффективного проведения Акутуализации Бэклога Продукта (PBR) в статье Эффективный PBR часть I. Статья, которую вы сейчас читаете, детально раскрывает технику Example Mapping.

Example Mapping для PBR

“Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации”
— Мэлвин Конвей 

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

  • Каждая команда – это самоуправляемая, кросс-функциональная, колоцированная, и долгоживущая структурная единица.

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

На встречу были приглашены 5 команд из продуктовой группы LeSS, стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности и, конечно же, Владелец Продукта. 

Наша цель заключалась в  том, чтобы детально проработать TOP-5 элементов Бэклога Продукта. 

Порядок действий был следующий:

1. Обозначили 5 хранителей знаний (экспертов) на каждому из выбранных элементов. Эти люди оставались на станциях все время.

2. Образовали смешанные группы из 5 команд, которые присоединились к экспертам.

3. Мы подготовили вымышленный пример фичи “Предотвращение нелегального использования топливной карты” и обучили группы технике Example Mapping

И объяснили цветовое обозначение для стикеров:

  • История — описание элемента Бэклога Продукта
  • Правило — это один из критериев по которому мы поймем что фича реализована как задумывалась, иначе говоря голубые стикеры — это критерии приёмки фичи
  • Пример — конкретный пример описывающий правило, Действие => Результат
  • Вопрос — если на текущий момент в группе возникает вопрос, на который группа не может в таком составе ответить, вопрос пишется на розовый стикер для дальнейшего прояснения

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

4. Запустили World Cafè — фасилитационный формат, где есть “хозяин” станции, в нашем случае им являлся эксперт, к которому присоединились группы участников. Группы работали на станциях: проясняли требования и наполняли флипчарт, используя Example Mapping.

По истечении времени группа переходила на следующую станцию и работала там с другим экспертом. И так продолжалось до тех пор пока все группы не побывали на всех станциях. 

5. После того как все группы побывали на всех станциях произошла презентация результатов работы.

Что у нас получилось:

  • Обратили внимание, что на одной из станции образуется большое количество вопросов. Оказалось, что много информации уже было написано в базе знаний, но прошло порядочно времени. Знания забылись. Мы нашли ноутбук, залезли в БЗ и выгрузили ключевые моменты на стикеры.
  • Большое количество голубых стикеров — сигнал к тому что эта фича большая. Хорошая новость! Ее можно разбить прямо по правилам!  
  • Все 5 команд продуктовой группы познакомились в равной степени с каждым элементом Бэклога Продукта (PBI), а значит каждая команда сможет взять любой из них на Планировании Спринта.
  • Правила, описанные на зелёных стикерах, уже в первый же день работы в Спринте могут использоваться для автоматизации приемочного тестирования. Более того, подход test-first теперь становится неизбежным 🙂

Попробуйте и Example Mapping! Будем рады услышать от вас идеи, ваши находки и улучшения 🙂

Напоминаем, что 14-16 октября у нас состоится первый тренинг Professional Scrum Developer (PSD) на русском языке — лучший тренинг для Скрам-команд, которые создают реальное программное обеспечение. На тренинге мы подробно разберём тему PBR, а также другие темы эффективной работы.

Читайте и другие наши посты про PBR в нашем блоге: Эффективный PBR часть I и Мультикомандное уточнение Бэклога Продукта

Из первых уст. Инсайты с конференции Liberating Structures European Gathering, Hamburg, August, 2019

Привет! Маленькая мечта сбылась: познакомилась с создателями освобождающих структур на конференции Liberating Structures European Gathering!

Конференция,  больше похожая на митап, проходила 8-9 августа 2019 в Гамбурге. Я ехала подготовленная — у меня было много вопросов к создателям освобождающих структур Генри Липмановичу (Henry Lipmanowicz) и Кейту МакКэнделсу (Keith McCandless).

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

Читать далее «Из первых уст. Инсайты с конференции Liberating Structures European Gathering, Hamburg, August, 2019»

Скрам — это дизайн совершенства!

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

Проблема с холодильниками

В 50-х годах компания General Electrics выпускала холодильники с дверцами двух видов: открывающихся или на правую, или на левую сторону. Компания никак не могла найти баланс между выпуском двух вариантов. Когда спрос одной модели превышал предложение, то покупатели вынуждены были ждать и уходили к конкурентам. Когда предложение превышало спрос, холодильники простаивали на складах и приносили убытки.

Было испробовано несколько стратегий:

  • Сначала менеджмент вообще ничего не предпринимал.
  • Отдел продаж начал прогнозировать спрос в регионах.
  • Подключили математическую статистику для уточнения прогнозов.

Результаты улучшились, но не устраивали менеджмент. Проблема разрешилась только тогда, когда General Electrics стала выпускать универсальные холодильники, двери которых настраивались на открытие в любую сторону.

“Решение” (resolution) и “растворение” (dissolving) проблем

История с холодильниками иллюстрирует различные подходы к управлению: игнорирование проблемы, поиск приемлемого, а затем более эффективного решения, и, наконец, “растворение” проблемы. 

Можно контролировать/управлять проблемами, приспосабливаясь к ним, а можно фундаментально устранять.

В системном мышлении считается, что наилучший способ решить проблему — сделать так, чтобы она не возникла вновь. Для этого нужно перестроить систему, т. е. изменить способы работы и взаимодействия частей системы.

Эффективный менеджмент заключается реструктуризации системы, а не решении проблем (Рассел Эйкофф, Воссоздание корпорации).

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

Проблема“Решение” проблемы“Растворение” проблемы
Распределенные команды и негативные последствия (недоверие, асинхронные зависимости, высокие издержки и потери при коммуникации).Эффективные электронные инструменты, качественная фасилитация, очные встречи, например, раз в квартал и т. д.Колоцированные команды, сидящие в одном помещении за одним столом.
Экономические потери, вызываемые очередями (длинные циклы, повышенная вариабельность, сниженное качество и мотивация).Управление очередями, сигнальные карточки (канбан), WIP-лимиты.“Идеальный поток”, работа в стиле one-piece flow, использование техник моб-программирования, swarming.
Зависимости между командамиУправление зависимостями (выделенные координаторы, встречи).Команды без зависимостей (кросс-функциональные и кросс-компонентные), которые непрерывно интегрируются.
Необходимость в координацииВыделенные координаторы, специальные централизованные встречи, координационные роли и подразделения.Создание условий для возникающей самоорганизации (децентрализованные техники координации, колокация команд, непрерывная интеграция в коде).
Читать далее «Скрам — это дизайн совершенства!»

7 токсинов доверия в команде

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

Что же является причиной снижения уровня доверия в команде. Ниже мой список основных токсинов.

Читать далее «7 токсинов доверия в команде»