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

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

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. Часть 2.

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

Этот блог-пост  – глава-прототип моей готовящейся к выходу книги Coaching Agile Organizations.

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

Некоторые элементы равнее, чем другие.

Ниже представлен упрощенный вид организационных элементов одного из моих клиентов.

Мы обнаружили, что некоторые организационные элементы требуются чаще, чем другие для разработки функциональности. Чем чаще требуется конкретный элемент, тем сильнее зависимость. Мы визуализировали силу зависимостей с помощью тепловой карты (heat map) – см. рисунок анонимного упрощенного примера ниже.

По шкале y находятся элементы функциональности. По шкале x – организационные элементы. Зеленый цвет показывает, какой элемент нужен, чтобы доставить этот элемент.

Элементы, которые “нагреваются” больше всего, указывают на силу зависимости – это горячие точки. Обратите внимание, что элемент WEB необходим в 28% времени для разработки функциональности продукта, APP– в 20% времени, в то время как для LEGAL требуется всего 7%.

ПРИМЕЧАНИЕ. Старайтесь не уделять слишком много внимания процентам, это не точная наука, а скорее руководство, которое поможет вам двигаться вперед. Помимо процентов, я также успешно использовал различные шкалы для оценки силы зависимостей, таких как: Редко, Сейчас и Затем, Частота.

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

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

Найдите баланс между адаптивностью и скоростью

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

Следовательно, размер области тепловой карты, которую охватывает команда, сильно определяет ее

  • скорость поставки фич
  • гибкость в выборе работы из Бэклога Продукта.

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

  • Когнитивные способности команд. Когда команды специализируются на клиентском домене, они могут по-прежнему работать с клиентскими фичами (end-2-end), не разбираясь в других клиентских доменах продукта.
  • Тип зависимостей между элементами. Это помогает командам определить какой организационный элемент охватить в первую очередь, а какой потом. 

Специализируйтесь на домене клиента

Наш продукт был большой системой страхования. Мы использовали интервью и анкеты, чтобы определить, где пользователи проводят большую часть своего времени при использовании продукта.  Оказалось, что было несколько основных групп пользователей (для этого блога я просто использую 2 группы «Заявки и оценка» и называю их красным и желтым). Некоторые пользователи в основном использовали фичи красного цвета – красную область, в то время как другая группа в основном использовала фичи желтого цвета – желтую область. Оранжевые фичи используются обеими группами пользователей: они перекрывают или пересекают как красные, так и желтые области.

Красные и желтые области позволяют командам специализироваться на домене клиента — см. Области требований в LeSS (less.works) и паттерн Области Ценностей. Это снижает когнитивную нагрузку на команды.

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

Тип зависимостей между элементами

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

  • Правило 1  Pooled Dependencies – содержание взаимных зависимостей внутри одной Области Ценности: Работа одной команды является входом для другой команды, и наоборот, и существует неопределенность в том, как выполнить задачу, что делает необходимым частое выравнивание. 
  • Правило 2 Sequential Dependencies – обеспечение последовательных зависимостей между Областями Ценностей с помощью итеративного планирования: команда зависит от работы, которая должна быть  выполнена другой командой. Применимо для работы с низкой неопределенностью и предсказуемой работой.
  • Правило  3 Reciprocal dependencies –  управление зависимостями между командами и Областями Ценностей с помощью простых правил координации: например, совместное использование единой тестовой среды или зависимость от человека с дефицитным навыком.

Ниже вы можете увидеть пример результата для красной Области Ценностей.

WEB, APP, SIEBEL, PORTAL компоненты часто используются вместе и их взаимозависимости двусторонние. Команды в красной области Команды красной области решили, что им нужно будет охватить хотя бы эти элементы.

Кроме того, вы можете увидеть, что область имеет объединенную взаимозависимость с LEGAL и что это относительно сильная зависимость. Самая слабая взаимозависимость – 14% с SALES FORCE. Мы решили не включать SALES FORCE изначально, а добавлять его только тогда, когда команды освоят другие элементы. LEGAL также не был включен, потому что это была общая зависимость.

Желтая Область Ценности ниже имела другой состав зависимостей.

Команды решили что им нужно охватить как минимум APP, SALES FORCE, SIEBEL и WEB компоненты.

Для этой области LEGAl был не нужен совсем. И слабая последовательная зависимость от PORTAl. Мы решили не включать PORTAl на первом этапе. В исключительном случае, когда какая-либо фича нуждалась в изменении PORTAl, команды могли координировать свою работу с красной областью, чтобы выполнить это. Мы также использовали это, как возможность, чтобы узнать больше о PORTAL.

Что делать с элементами функциональности в пересекающейся оранжевой области? Решение состоит в том, чтобы решать, на основе самой фичи.

Например, F10 может быть выбрана как красной так и желтой областью. F18 задействует только APP и может быть выбрана желтой областью. Единственная сложная фича – F11. Она задействует SALES FORCE и PORTAL, которых нет ни у красной ни у желтой области. Итак, как быть с ней? Хорошо…., вспоминаем золотое правило Скрам-мастерства: “Всегда спрашивай команду.”

Итоговый результат

Определение продукта включает все элементы, но мы выбрали не включать LEGAL-компетенции ни в одну из команд на старте. Почему? Потому что это общая и слабая зависимость. Кроме того, команды чувствовали, что еще не готовы охватить больше навыков с самого начала. Вместо этого, LEGAL стал следующей активностью для включения в Definition of Done.

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

На Планировании Спринта, команда, которая выбирает эту фичу будет координировать свою работу с кем-то из LEGAL для ее завершения. Предпочтительно, чтобы члены LEGAL также использовали эту возможность, чтобы обучать команду, чтобы они немного больше узнали о LEGAL к концу Спринта. Когда команда продолжает выбирать фичи LEGAl-компонентом, в конечном итоге они обучатся достаточно, чтобы добавить LEGAL в Definition of Done. Бас Водди называет это случайной специализацией. 

ПРИМЕЧАНИЕ. Не всем командам необходимо знать все обо всех элементах определения продукта с самого начала. Команды могут иметь свою специализацию до тех пор, пока все команды в группе смогут выбирать все элементы из верхней части Бэклога Продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О чем статья

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

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

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

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

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

Трансформационный долг и пределы роста

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

Успех первых пилотов

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

Читать далее «Трансформационный долг и пределы роста»

Мы не верим стикерам! Или как аналитики Рук поставили под сомнение результаты Воркшопа по Продукту

Кто мы и чего хотели

Мы — команда Рук (https://hands.ru), — пришли к необходимости сформировать SCRUM-команду для работы с продуктовым бэклогом. Для этого мы попросили Илью Павличенко и Рому Дорошенко провести у нас воркшоп по продукту, на котором мы разбирались, на какие компоненты можно разложить задачи из бэклога и какие компетенции потребуются в SCRUM-команде.

Табличка компонент бэклога

Так выглядят таблицы компонент (HitMap) и компетенций (FTAM), выработанные за время воркшопа:

Таблицы вызывали некоторое недоверие: они очень большие и оттого “непрозрачные”. Чтобы получить какое-то понимание, мы решили покрутить таблицу компонент и посмотреть, что и как поменяется. Имели в виду при этом такие соображения: Читать далее «Мы не верим стикерам! Или как аналитики Рук поставили под сомнение результаты Воркшопа по Продукту»

Эшелоны Полёта: уровни организационного улучшения

Перевод оригинальной статьи  «Flight Levels: The Organizational Improvement Levels»

Когда вы записываете какую-либо идею, вы смотрите на неё, обдумываете и продолжаете её разрабатывать. Именно так произошло и с моделью Эшелонов Полёта (Flight Levels). Её уже много раз обсуждали на консультациях с клиентами, на тренингах и презентациях. Несмотря на это, как только была опубликована моя книга «Канбан на практике», я изменил свою точку зрения насчёт Эшелонов Полёта благодаря обратной связи от читателей, слушателей и участников тренингов.

Читать далее «Эшелоны Полёта: уровни организационного улучшения»

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

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

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

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

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