Как измерить Agile?

2 июля мне в ленте попался ролик Артура Нека на тему "Почему Agile команды не имеют ничего общего с бизнес гибкостью". По существу, это был перевод исходного ролика Клауса Леопольда "Why Agile Teams Have Nothing To Do with Business Agility" двухгодичной давности. Суть этих роликов очень простая. Если вы вот уже несколько лет безуспешно пытаетесь внедрить agile-фреймворки в вашу организацию с целью сделать бизнес более гибким, прекратите это делать. Внедрите канбан-метод и будет вам искомая гибкость.

Изначальная цель была - улучшить T2M в проектах. Для них это означало, цитирую be proactive on the market, exploit oppurtunities in the market, be prepared for continuous change (обратите внимание, какая основная цель и как она декомпозирована). В качестве решения они выбрали agile-трансформацию. Кросс-функциональные команды разработчиков, каждая команда работает только над одним продуктом, команды сами выбирают себе фреймворк. Каждая команда должна использовать визуализацию работы на доске, ежедневные стэндапы, ретро и измерять свою эффективность по lead time и throughput (обратите внимание на эти метрики).

1.5 года трансформации вовлекали 600 сотрудников, которых загнали на базовый однодневный agile тренинг. Реорганизовались в команды, обучили скрам-мастеров и владельцев продуктов (если команды выбирали scrum), delivery-менеджеров (если команды выбирали kanban-метод). В начальной фазе в компании работали 16 приглашенных agile-коучей, которые обучали и фасилитировали, после чего они образовали 11 agile-коучей внутри.

Через 1 год от начала всё шло по плану, 80% команд успешно трансформировались. Но метрики были грустными. Scrum sprint velocity и lead time оставляли желать лучшего. Причины были в зависимостях между командами, делающими один и тот же продукт: ежемесячная интеграция и квартальный релиз. А ещё там были жутко длинные циклы предварительной обработки задач перед бэклогом: ежемесячные idea triage, квартальные steering committee и полугодичный approval.

Вывод делается следующий. Исходя из увиденного, кстати, вполне логичный. Если это Agile software development, то тогда он не имеет ничего общего с business agility.

Мой вопрос - а вы уверены, что это agile software development? Мой ответ - нет. И основная проблема не в том, насколько качественно имплементировали Agile-фреймворки. Основная проблема в том, как выбирали инструмент решения исходной задачи: улучшить T2M в проектах. Первичная декомпозиция исходной задачи немножко намекает на agile, но то, как его измеряли - по lead time и velocity - полностью подтверждает вполне предсказуемый fail.

Как надо правильно измерять agile написано, например, в EBM guide. Сразу оговорюсь, я не вижу смысла рассматривать Agile только в контексте Software Development. Он также хорошо работает и вне-IT. И чтобы быть правильно понятым в данном контексте, я намеренно заменяю слово "production" на "средства производства". Соответственно, инкремент - атомарное изменение средств производства, которое повышает ценность. Если вам кажется, что я придумал что-то своё - я уважаю такое мнение, однако отвечать на такие комментарии не буду, ибо пустое. Не нравится? Я не навязываюсь, идите мимо своей дорогой. А для остальных я продолжу.

Business Agility напрямую зависит от ценности и способности организации поставлять эту ценность. Ценность измеряется не в абстрактных value points, а от бенефициаров организации (например, акционеров). Какие у них стратегические цели? Как их измерить? Какое текущее состояние организации по этим метрикам? Кроме самой ценности, Business Agility зависит также от способности организации модернизировать средства производства в двух аспектах: время поставки ценности (Time-to-Market) и эффективность оптимизации ценности (Ability-to-Innovate). Для каждой из этих 4х областей EBM guide предлагает от 3х до 12-ти конкретных метрик, которые можно попробовать.

Измеряя только Time-to-Market, клиенты Клауса Леопольда фактически создали запрос на оптимизацию поставки, но не на оптимизацию ценности. Они никак не измерили свои, вполне здоровые смыслы, странным образом заложенные в главную, весьма однобокую цель (улучшить T2M в проектах): be proactive on the market, exploit oppurtunities in the market, be prepared for continuous change. Это основная причина провала agile-трансформации. Канбан-метод, конечно же, зашел как нельзя лучше именно по этой причине - как измерили желаемую Business Agility, как Time-to-Market: throughput, lead time.

Да, после успешного решения этой задачи, Клаус пошел дальше и сделал то, что напрямую влияет на Business Agility - целеполагание бизнеса, стратегия, workflow для отработки идей (гипотез) через их итерационную проверку. Вобщем, взяли канбан-метод, и добавили сверху много всякой другой экспертизы, и получился реально крутой кейс. Как в сказке про кашу из топора. И из этого сделали вывод, что Agile-фреймворки не годятся для решения задачки с Business Agility.

Я соглашусь, что таково состояние рынка agile по факту - почти всегда продуктовые Agile-команды состоят только из IT-специалистов. А остальные составляющие функции цикла поставки и оптимизации ценности остаются традиционными. Scrum-мастер (чаще) и Agile-коуч (реже) фокусируется только на IT-функции и... застревает там надолго, выгорает, переходит на следующую работу, опять выгорает. Декларации о том, что Agile-фреймворки - это не командные, а организационные фреймворки, не помогают. Так и хочется спросить: вы долго ещё будете сидеть в своих командах и крутить спринты? Что вам не хватает, чтобы выйти на уровень бизнеса и организации?

Однако, значит ли это всё, что Agile-команды в принципе не могут повысить Business Agility? Да, канбан-метод - отличный инструмент. Однако, в руках дилетанта канбан-метод для повышения Business Agility также плох, как и, например, Scrum. Справедливо ли будет называть инструмент плохим только на основе того, что его непрофессионально применяли? Является ли какой-то инструмент хорошим только на основе того, что его используют профессионально?

Для меня самое удивительное в этом ролике от Артура было в том, что я узнал свою собственную ситуацию несколько лет назад. Я тоже успешно применил канбан-метод, когда Agile-фреймворки никак не помогали бизнесу с IT в течение нескольких лет. Именитый Agile-коуч не справился. Я тоже по-началу не справился со своим любимым Scrum. Реальный PO (владелец) постоянно сливался со своей роли, выставляя между собой и командой посредника. А делегировать посреднику функции mini-CEO он не решался.

Канбан-метод помог мне решить проблему в IT, не меняя mindset владельца. Но бизнесу-то от этого, как вы понимаете, легче не стало. Ему потом стало легче от Customer Development и Lean Startup Management, которые, кстати, создают процесс, очень похожий на то, что описано в EBM guide. Но эта история уже выходит за рамки канбан-метода, ровно как это произошло и у Клауса. И я целиком и полностью поддерживаю, и до сих пор использую канбан метод. Более того, Эрик Рис предлагает использовать канбан для учета инноваций в своем бестселлере. Поэтому, товарищи канбанёры, не надо в меня тухлыми помидорами кидать - я за вас, я не против вас.

Наверное, у читателя возник вопрос - а зачем вообще нужны Agile-фреймворки, если гораздо легче и проще всё получается через канбан-метод? Догрузить экспертизы сверху и все дела.

А все эти простые на первый взгляд agile-фреймворки, которые по идее уже содержат необходимые конструкции для скорейшей продуктовой трансформации, настолько сложны в применении на практике (easy to learn, difficult to master), что из всей нашей армии scrum-мастеров и agile-коучей лишь только единицы реально могут и делают. Agile-фреймворки, будучи правильно вкрученными создают на всех уровнях организации такую боль, что эффективность организации в целом сначала даже проседает, и только потом отыгрывает и растет дальше (пресловутая J-curve). Практика применения канбан-метода лишена этих недостатков.

И всё же я топлю за agile-фреймворки, и утверждаю, что их ценность сейчас даже выше чем 10 лет назад, и она будет только повышаться. И вот почему.

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

Учитывая информационное состояние общества и его динамику на момент написания этой статьи, время на игры с визуализацией и эволюционной трансформацией процессов стремительно тает. Мы уже давно проскочили состояние VUCA и приехали в BANI. Скоро у большинства компаний не останется шансов выжить без революционной трансформации. Поэтому, нам очень нужно что-то делать со сложившимся рынком agile, и scrum. Рынок терпит наш слабый профессионализм и откровенно узкое мышление из-за дефицита. Но как долго он продолжит это терпеть?