Почему Аджайл-трансформация буксует

Знаете ли вы компании, которые используют Аджайл-практики и внедрили Скрам, но так и не получили ощутимых результатов после нескольких лет трансформации? Чаще всего дело в том, что цели оптимизации адаптивность и скорость противоречат организационному дизайну компании, который поддерживает другие цели. В этой статье мы научимся находить несоответствия между целями оптимизации и текущей структурой. 

POSIWID (“Purpose Of The System Is What It Does”)

Специалист по системам и управлению Стаффорд Беер разработал важную и популярную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Другими словами, цель оптимизации определяет результаты системы. Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. 

Когда люди понимают, как цель системы и ее структура определяют результаты, они могут взять на себя ответственность за изменению структуры.

Давайте приведем примеры, где ЗАЯВЛЯЕМАЯ и ФАКТИЧЕСКИЕ цели систем не совпадают.

СистемаНаблюдаемая проблемаЗаявляемая цельЦель, сформированная с помощью POSIWID
ШколаМного не вовлеченных детейВоспитание полноценных и самостоятельных людейШкола хорошо достигает цели в том, чтобы сделать обучение для детей как можно более скучным
Программное обеспечение XYZБольшой отток клиентовПомощь малому бизнесуПродукт прекрасно достигает цели в том, чтобы заинтересовывать клиента, а затем сделать все возможное, чтобы он ушел.
ПарламентКоррупция, слияние власти с крупным бизнесомПредставлять интересы граждан и защищать их интересыПарламент замечательно выполняет цель, которая заключается в обогащении и лоббировании интересов крупного бизнеса.

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

Каждая система идеально разработана для достижения результатов, которые она получает. (Дон Бервик)

Хороший пример, когда поставленная цель не работает — Copy-Paste масштабирование. Это самый распространенный способ использования Скрама в больших организациях по всему миру. 

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

Такая структура порождает зависимости и длинные релизные циклы. Кроме того, команды работают не над самой важной функциональностью из-за наличия многочисленных Бэклогов Продукта. Copy-Paste масштабирование имеет мало общего с заявленными оптимизационными целями. Чаще всего фактические цели оптимизации: сохранение статуса-кво и структур власти, индивидуальная эффективность, создание видимости изменений для того, чтобы отрапортовать руководству о том, что “трансформация завершена”. Поэтому фактическая цель, определенная с помощью POSIWID, может звучать так: 

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

Итак, можно до посинения доказывать, что целью системы является [XYZ], но если это не подтверждается результатами и поведением системы, то это ЗАЯВЛЕННАЯ цель, а не ФАКТИЧЕСКАЯ. Давайте дальше разбираться в том, как привести к соответствию цели оптимизации и организационный дизайн.

Читать далее «Почему Аджайл-трансформация буксует»

Определение продукта в LeSS. Часть 1.

Перевод оригинальной статьи Сезарио Рамоса.

Это первая часть серии блог-постов об определении продукта в LeSS.

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

Узкое определение продукта создает различного рода проблемы для продуктовой группы. Узкое определение продукта локально оптимизирует производительность команд за счет производительности группы. Системная диаграмма (CLD) ниже объясняет эту динамику. 

(См. Этот блог-пост для краткого обзора обозначения CLD.)

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

Устраните локальную оптимизацию узкого определения продукта

Часто используемое определение продукта – «что-то, что сделано для продажи». Продукт обеспечивает способ извлечения прибыли.

  • У продукта есть пользователи, люди;
  • Продукт предоставляет базовую функциональность, которая закрывает проблемы и отвечает потребностям пользователей;
  • Продукт имеет бизнес-модель, источники доходов, независимую прибыль и убыток (P&L) или возврат инвестиций (ROI).
  • Продукт разрабатывается и поддерживается системой людей, компонентов и процессов.

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

Как определить продукт?

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

Шаг 1 — Определите необходимые организационные элементы для разработки и поддержки продукта.

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

Типичные шаги для достижения этой цели:

  • Определите типичных внешних конечных пользователей для вашей группы.
  • Определите постоянные потребности, которые эти конечные пользователи хотят решить, или задачи, которые они должны выполнить.
  • Определите фичи для каждого из пользователей, которые они используют для удовлетворения потребностей или выполнения своей работы.
  • Определите каналы, через которые пользователи используют функции для удовлетворения своих потребностей/проблем и т. д. (Например, Браузер, Приложение, API, Connector или Helpdesk)
  • Затем, определите организационные элементы, которые вам необходимы для разработки фичи и удовлетворения пользователя. Сделайте это, изучая путь, как каждый элемент функциональности проходит через вашу организацию в руки клиента. Начните с каналов, проработайте компоненты, системы, людей и процессы до конца пользовательского пути.

Шаг 2 – Проясните источники доходов

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

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

  • Как элементы вместе генерируют деньги? Например, может ли определение продукта иметь плату за использование? Продажа активов? Абонентская плата? Лицензирование? Если нет, что нужно добавить к определению продукта?
  • Имеет ли определение продукта независимый P&L? Если нет, то какие организационные элементы отсутствуют? 
  • Какие KPI можно назначить определению продукта? Например, можете ли вы назначить увеличение валового дохода? Увеличение новых клиентов? Удовлетворенность клиентов?

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

Определение продукта завершено?

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

С такой большой группой вы можете спросить себя: «Как я могу создать эффективные кросс-функциональные команды, которые включают все эти компетенции? В случае более чем десяти групп, мы рекомендуем организовать команды среди Области Ценностей  и содержать зависимости для каждой области.

Это тема моего следующего блога.

7 принципов упрощения организаций

Перевод оригинальной статьи Баса Водди и Крэйга Лармана.

Зачем компаниях Аджайл или LeSS? К сожалению, многие организации стремятся повысить эффективность отдельных людей и команд. Фокусируясь на отдельных активностях, “выхлопах” (outputs), скорости (velocity) и утилизации ресурсов, они не осознают, что это обычно приводит к снижению доставляемой ценности и адаптивности, удлинению циклов разработки фич для клиентов. LeSS нацелен не на локальные оптимизации (такие как рост персональной эффективности), а на оптимизацию организации для повышения ценности, доставляемой клиентам, и адаптивности —  скорости, с которой организация может менять направление разработки, опираясь на обучение.

Как же построить гибкую и адаптивную организацию? Упростив ее!

Читать далее «7 принципов упрощения организаций»

У вас “Chief Product Owner” и Copy Paste Scrum?

О чем статья

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

Мы называем эту модель Copy Paste Scrum и она вызывает целый ворох проблем:

  • Зависимости между командами и вынужденную координацию;
  • Отсутствие сквозных приоритетов и работу над менее важным;
  • Хрупкость системы;
  • Оторванность разработчиков от бизнеса и клиентов;

В общем случае Copy Paste Scrum — фейковый Скрам. В этой статье я объясню почему, а затем мы разберемся в том, как разрабатывать большие продукты, используя Скрам профессионально.

Читать далее «У вас “Chief Product Owner” и Copy Paste Scrum?»

Непрерывная интеграция

Перевод неустаревающей статьи Мартина Фаулера про Непрерывную Интеграцию. Несмотря на то, что статья написана в 2006 году и упоминаемые в ней инструменты уже устарели, описание самой практики остаётся актуальной и по сей день.


Непрерывная интеграция ― это практика разработки программного обеспечения, в которой участники команды часто выполняют интеграцию своих изменений. Как правило, каждый участник выполняет интеграцию как минимум раз в день, и в итоге достигается такой режим работы, при котором интеграция выполняется несколько раз в день. Каждая интеграция проверяется путем автоматической сборки (включающей тестирование), что позволяет находить ошибки интеграции как можно скорее. Многие команды убедились, что такой подход существенно снижает количество интеграционных проблем и позволяет быстрее разрабатывать целостный программный продукт. Эта статья представляет собой обзор непрерывной интеграции, описывающий эту технику и то, как она используется в настоящее время.

1 мая 2006 г

Мартин Фаулер

Содержание

Читать далее «Непрерывная интеграция»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image copyright by EBG Consulting

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

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

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

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

8 привычек адаптивных организаций 21 столетия!

8 привычек высокоэффективных организаций или
управленческие тренды 21 столетия! Какие они? И насколько Scrum и LeSS «успевают» за этими трендами 🙂
Когда читал этот список, составленный компанией Corporate Rebels, то улыбался, потому что все 8 пункты уже «встроены» в фреймворк Scrum и его масштабируемый вариант LeSS. Оригинальная статья доступна по ссылке, а здесь я кратко опишу пункты на русском.
 
Итак, список из восьми пунктов «адаптивных» или «прогрессивных» организаций, как их называют в статье Corporate Rebels.
 
1. Фокус на ценностях и большой миссии, а не на деньгах только. Подобный подход дает людям энергию, страсть и мотивацию. Люди хотят быть частью чего то большего, а не просто зарабатывать деньги.
 
2. Организационная структура, основанная на нетворке команд, уход иерархической структуры. Иерархия медленна, лишена гибкости, задерживает быструю доставку ценности на рынок.
 
3. Поддерживающее лидерство, уход от директивного командно-контрольного стиля управления. Задача современного управленца — создание условий и окружения для максимального раскрытия потенциала сотрудников, создание культуры непрерывного улучшения. Управленцы являются носителями миссии и ценностей, они пример для других.
 
4. Переход к эмпирическому контролю процессов, гибким планам, уход от планирования, основанном на предсказаниях. Адаптивные организации предпочитают подход «fail fast».
 
5. Свобода и доверие важнее правил и контроля. Работники это взрослые люди, которые сами могут контролировать себя и брать на себя ответственность. Задача управленцев — создать необходимые условия для этого.
 
6. Переход от централизованной модели управления к децентрализованной. Адаптивные организации передают принятие решений на периферию тем, кто каждый день общается с клиентами и лучше знает их боли и потребности.
 
7. Переход к радикальной прозрачности. Абсолютный доступ к финансовым данным, любой информации в реальном времени. Это ускоряет принятие решение и делает их более эффективными.
 
8. Уход от формальных должностных инструкций и фокус на обучении сотрудников и раскрытию их потенциала. Границы между ролями становятся более размытыми.
 
#Agile #Scrum #LeSS #ScaledScrumIsStillScrum

Повышаем гибкость с 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)»

Почему создание «Центра Аджайл-компетенции» очень плохая идея

Перевод оригинальной статьи Энтони Мерсино “Why an Agile Center of Excellence is a Really Bad Idea”

Многие компании создают специальные подразделения для сопровождения Аджайл-трансформаций. Они получают разные названия. Два варианта, которые я считаю совершенно неудачными, это “Центр Аджайл-компетенции” и “Офис управления Аджайл-проектами”. Я считаю, что создание подобных подразделений вообще плохая идея. Объясню почему.

Среди целей создания таких подразделений часто указывается, что они призваны «способствовать гибкости организации». Звучит здорово, правда? Но на самом деле их деятельность, напротив, мешает гибкости. Часто “Центр Аджайл-компетенции” практически полностью фокусируется на стандартизации процессов и инструментов, а также на масштабировании и эффективности. Казалось бы, что не так?

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