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.

Читать далее «Прокачайте PBR при помощи Example Mapping»

Из первых уст. Инсайты с конференции 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 токсинов доверия в команде»

Что такое продукт?

Что такое продукт? 

Перевод оригинальной статьи Ellen Gottesdiener “What is your product?”

«Что такое продукт?» Это ключевой вопрос, который я недавно опубликовала в своем докладе в преддверии конференции Agile Cincinnati.

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

Каждый в продуктовой разработке должен иметь общий для всех, последовательный и четкий ответ на вопрос: «Что такое продукт?»

Image copyright by EBG Consulting

У компании должен быть общий для всех сотрудников, последовательный и четкий ответ на вопрос: «Что такое продукт?»
Изображение от EBG Consulting

Пять принципов

Существует пять принципов, которые помогают определить продукт:

Читать далее «Что такое продукт?»

Традиционное и системное мышление

Перевод статьи Сезарио Рамоса Systems and traditional thinkers

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

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

«95 % проблем в бизнесе возникают на уровне систем и только 5 % на уровне людей».

Э. У. Деминг

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

Но что представляет собой система? Р. Л. Акофф предложил лучшее, на мой взгляд, определение:

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

Читать далее «Традиционное и системное мышление»