Обзор книги Клауса Леопольда: Переосмысляя Agile

Клаус Леопольд является основателем компании LEANability и одним из драйверов мирового Канбан-сообщества.

Подход, описанный Клаусом, будет интересен топ-менеджменту и лидерам изменений, которые ищут эволюционный и действенный способ ускорение потока создания ценности всей компании.

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

Если резюмировать книгу в одном предложении, то это будет:

Часть 1. Проблема «Мы хотим адаптивности бизнеса!»

Типовые цели Agile/Digital-трансформации:Топ-менеджеры смотрят вокруг: в других компаниях используются Scrum, Kanban, SAFe, LeSS — и компания решает, что ей тоже надо быть Agile. 

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

Обычно, руководство задает ключевые рамки для команд: 

1. Кросс-функциональность.
2. Одна команда, один продукт.
3. Базовые требования к методам работы: 
   • визуализация работы;
   • ежедневные стендапы;
   • регулярные ретроспективы;
   • метрики времени цикла и пропускной способности.

Это звучит логично.

Однако, через 12 месяцев внедрения Agile, мы наблюдаем такую картину:

1. Суммарная пропускная способность команд не увеличивается.

2. Среднее время производства задач не уменьшается.

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

Часть 2. Причины

Причина 1. Подмена ценности

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

Еще хуже, когда компания слепо копирует оргсхему Spotify, не понимая, что это модель одной музыкальной компании 2012 года. Сейчас она серьезно видоизменена и не факт, что поможет решить те вызовы, которые стоят перед вашей компанией сейчас. Первое, что Spotify говорят, когда приезжаешь к ним на экскурсию: “Ради Бога, не копируйте нашу оргсхему, пройдите этот путь сами!”

Причина 2. Работа с зависимостями

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

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

Важно понимать, что на 100% вы не избавитесь от зависимостей, но вы должны:

1. уменьшить их по максимуму;
2. наладить четкий процесс управления оставшимися.

Однажды Рассель Акофф сказал: “Производительность системы НЕ равна сумме производительностей ее частей, это всегда вопрос их взаимодействий”.

Представьте, что компания — это клавиатура.

Причина 3. Не полный поток создания ценности

 Во многих компаниях распространены Канбан-доски, обычно они ограничены зоной ответственности команды и не содержат весь поток создания ценности (value stream).

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

И, конечно же, не надо забывать про Upstream-поток (иногда эту часть процесса еще называют Discovery). Там могут быть такие этапы как:

• формировании идеи;
• триаж идей (первичные анализ и отсев);
• описание бизнес-кейса (черновика);
• комитет и принятие решения go/no-go;
• уточненный бизнес-кейс;
• снова комитет.

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

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

Причина 4. Ограничение WIP в неправильном месте

Ограничение незавершенной работы (Work In Progress Limits, WIP-лимиты) нужны для повышения предсказуемости и скорости поставки. Типичная картина с больших компаниях: на 10 человек 100-200 задач в процессе.

Когда закончится каждая? Не ясно. Как такое количество задач может выполняться одновременно? Никак!

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

Забавно, что часто колонки с активной работой называются In Progress, хотя вернее было бы назвать In Process, так как по 90% задач прогресса нет в любой отдельно взятый момент времени.

Метрика, которая показывает эффективность потока, в больших компаниях обычно колеблется на уровне 10-15%. Она рассчитывается как отношение времени, когда производится реальная работа, к общему времени поставки. Представьте, какой есть запас для ускорения.

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

Часто наблюдаю ситуацию, когда команда работает с потоком декомпозированных задач, каждая из которых ценности сама по себе не несёт. Плюс в этом же потоке задачи «техдолга», «автоматизации тестирования» и т.п. Так вот у этого потока эффективность выше 60% не редкость. Машинка по переработке задач в учётной системе летит на всех парах. Только ценности из неё вытекает в разы меньше, чем можно было бы ожидать.

Это ведёт к конфликтам и противостоянию бизнеса и разработки. Разработка искренне считает, что они работают отлично. Ведь все профессионалы и все работают изо всех сил. А бизнес печалится, глядя на конечный бизнес-результат.

Всю неактивную работу надо рассматривать как пул возможностей (option pool) и выстраивать исходя из экономики (оптимизации возврата инвестиций). Детали такой приоритезации можно почерпнуть в книге «The Principles of Product Development Flow» Дона Рейнертсена.

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

Применяйте WIP-лимиты на том уровне, где компания хочет видеть максимальный эффект: уровень команды/проектов/стратегических инициатив.

• Если вы хотите ускорения проектов, то действуйте на уровне координации команд.
• Если вы хотите ускорения портфеля стратегических инициатив, то лимитируйте работу в нем.

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

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

Помните, что цель WIP-лимитов НЕ тормозить все и вся, а поддерживать бизнес-решения. Люди не должны постоянно работать, они должны постоянно доставлять ценность.

Проведите простой тест “Нужно ли вам менять или вводить WIP-лимиты?”

Если	Тогда
Вы и ваши клиенты довольны производительностью компании	Поздравляем, вы достигли оптимального WIP-лимита
Все двигается медленно, клиенты жалуются и бизнес-показатели не растут так, как хочет компания	Вводите WIP-лимиты
Мы поставляем на рынок быстрее, чем ожидают наши клиенты	Мало у кого такие проблемы, поздравляю! Вы можете начинать больше работы.

Подытожим 4 типовые проблемы бизнес-гибкости компаний:

1. Вопросы адаптивности возложены только на команды.
2. Слабое управление зависимостями.
3. Не видно сквозного (end-to-end) потока создания ценности, или он не управляется.
4. Нет управления портфелем и приоритезации гипотез по ценности.

Часть 3. Решение

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

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

Flight Level 1. Операционный уровень (или уровень команд)

Команды могут улучшать свой поток через 4 простых практики:

1. Визуализировать работу.
2. Ограничить незавершенную работу (WIP).
3. Наладить циклы обратной связи (ежедневный стендап, демо продукта, ретроспектива процесса, метрики).
4. Определить точки роста и работать над ними.

При этом конкретный метод или процессный фреймворк не так важен.

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

Между командами могут быть зависимости, это приводит нас к необходимости управления ими для оптимизации всего потока. Таким образом, мы приходим к Flight Level 2: уровню координации.

Flight Level 2. Координационный/программный уровень

Level 2 — это координация от идеи до реальности, до получения итоговой ценности пользователя или бизнеса. На этом уровне оптимизируется взаимодействие между командами. Сложно представить себе кросс-функциональную команду, включающую маркетинг, разработку, поддержку.

На этом уровне работают все те же практики, которые  команды применяют и у себя:

1. Визуализировать работу.
2. Ограничить незавершенную работу
3. Наладить циклы обратной связи (частый стендап, ретроспектива с представителями команд, метрики).
4. Определить точки роста и сосредоточиться на них.

Вы сразу увидите время простоя и узкие места.

В большой компании может быть несколько потоков создания ценности или продуктов, в этом случае на втором уровне будет несколько досок, а также доска для управления операционным портфелем (operational portfolio management). Это ответственность уровня 2.

Flight Level 3. Управление стратегическим портфелем

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

Важные примечания

1. Надо понимать, что в этой модели нет шаблонов досок, которые можно взять и скопировать.
2. Модель не надо использовать для реструктуризации компании.
3. Модель не является моделью зрелости (внедрение уровня 3 не означает большую зрелость по сравнению с внедрением уровня 2), она визуализирует и оптимизирует разные типы работ.

Иногда компании совмещают уровни 2 и 3 на одной доске.

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

• небольшие задачи должны оставаться внизу;
• а крупные инициативы (например “Сделать меньше Time-To-Market”, или “Запустить новый продукт”, или “Выход в новую страну”) не должны оставаться на нижнем уровне.

Однако, опыт показывает, что чаще всего компании стартуют с уровня 2 для эволюционного изменения проектной деятельности. Чтобы понять, с какого уровня стартовать, задайте себе вопрос: “На каком уровне вы ожидаете максимального эффекта?”

Самые распространенные инструменты

Улучшение №1. Создайте доски продукта для управления зависимостями

Это НЕ заменяет постоянные усилия для уменьшения зависимостей! На воркшоп по проектированию досок соберите представителей команд. Если у вас немного команд, то продуктовая доска может заменить доску команды. Дальше вводите WIP-лимиты для ускорения и налаживайте циклы обратной связи.

Улучшение №2. Интегрируйте Discovery Upstream для проектов

2 типовых проблемы Discovery Upstream:

• Годовой бюджет заставляет создавать большие задачи

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

• Слишком подробные требования

Часто подробные требования являются следствием отношения бизнеса к разработке как к аутсорсингу. Бизнес требует точных оценок, а точные оценки с железобетонными обязательствами можно сделать только с подробными требованиями и ценой больших усилий. Пересмотрите подход к оценке. Если у вас 5 дней уходит на оценку того, что делается за 1 день, то вы просто увеличиваете Time-To-Market на ровном месте. Можно применять грубую оценку размера проекта: 1, 2, 3, 5, 8 или Small, Medium, Large, Extra large.

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

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

Точки координации Level 2:

• Регулярная встреча по продукту с представителями команд два раза в неделю для управления зависимостями.
• Встреча по пополнению:
  • Прекратите начинать → Начните завершать (Stop starting →  Start finishing).
  • Если WIP заполнен, то не встречайтесь.
• Кросс-командные ретроспективы с представителями команд:
  • Это не отменяет внутри-командные ретроспективы.
  • НО важно следить, чтобы командные ретроспективы не приводили к локальной субоптимизации, на них должны вытягиваться проблемы важные для всего потока создания ценности.
• Регулярный сбор и анализ продуктовых и процессных метрик для объективной обратной связи.

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

Улучшение № 4. Стратегический портфель

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

Для оптимизации Тime-To-Market топ-менеджмент должен управлять объёмом текущей работы.

Отличие Lеvel 3 от уровней Level 1 и 2 в том, что Lеvel 3 работает с бизнес-эффектом, а уровни ниже с продуктовыми и процессными метриками.

Пример доски Lеvel 3 (просьба не копировать 1 в 1):

Не забывайте, что стратегический уровень также нуждается в обратной связи.

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

Обязательны ежеквартальные обзоры стратегии. На них смотрим, как мы продвигаемся, как продвигаются конкуренты. Корректируем тактические планы. Здесь отлично работает подход к адаптивному целеполаганию Objectives & Key Results (OKR).

Резюмируя улучшения в той компании, на которой построен кейс, можно отметить следующее: 

1. Показатель Time to Market уменьшился вдвое.
2. Компания научилась улучшаться сама на всех уровнях, а не только на уровне команд.
3. Научились быстрее обрабатывать обратную связь от пользователей.
4. Люди в командах стали понимать, куда идёт компания, с точки зрения стратегии.  Появился фокус на самом важном. 

Финансовые результаты были очень позитивными:

1. Ускорение поставки ценности выразилось в дополнительной прибыли в 10 миллионов евро
2. Если раньше рост доходов был 2-4 процента в год, то теперь он вырос до 25 процентов.
3. За три года прибыль выросла в три раза из-за более эффективной работы и выросших доходов.
4. Рыночная капитализация выросла с 3.4 до 7.1 миллиардов евро.

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

А если вы стали производить на 8 процентов фич больше, при этом они никому не нужны, то значит у вас просто на 8 процентов больше мусора.

Если Вам интересно узнать подробнее об инструментах бизнес гибкости, приходите к нам на курсы:

• Масштабирование Agile по SAFe®
• Lean-управление портфелем по SAFe®
• Управление программами и портфелями в Agile