Перевод статьи David J Anderson, размещённой на djaa.com.
Оригинал можно прочитать здесь.
Однажды клиент попросил меня представить карту совместимости моей модели организационной зрелости и паттернов зрелости Канбан с моделью Agile Fluency™ Джима Шора и Дайаны Ларсен, усиленной при поддержке Мартина Фаулера. Запрос клиента был основан на простой потребности: его организация уже в некоторой степени была знакома с моделью Agile Fluency и, следовательно, он хотел, чтобы я мог объяснить его людям, как моя модель отображается в контексте, который они уже понимают. Я решил, что будет полезно поделиться своими мыслями по этому поводу с более широким кругом читателей.
Вступление
Если вы не знакомы с моделью Agile Fluency, то вы можете прочитать базовую статью здесь. Я знаю Джима Шора и Дайану Ларсен около десяти лет. Время от времени я встречаюсь с ними на конференциях. Самая последняя наша встреча была в Мальмё на Øredev в ноябре прошлого года, где я произносил вступительное слово на тему социальной инженерии.
Джим и я испытываем взаимное уважение, признавая, что у нас очень разные подходы к повышению гибкости. Как говорит Джим, он практикует «кайкаку» (большое управляемое изменение), а не эволюционное «кайдзен». Джим работает только с клиентами, желающими заменить существующую систему разработки программного обеспечения его Agile-методом. Поэтому мы находимся на двух разных концах спектра. Также Джим склонен работать в небольшом масштабе: в командах от 2 до 12 человек и в небольших отделах. Я же работал с клиентами, пытающимися выполнить планирование сервисов уровня предприятия (ESP) c намерением увеличить число сотрудников до 100 000 человек. Выявив различия, теперь можно составить некоторое представление о том, как можно сопоставить Agile Fluency с паттернами Канбан и организационной зрелостью.
На рисунке 1 показана модель Agile Fluency, воспроизведенная непосредственно с оригинального веб-сайта. На рисунке 2 показана моя недавняя модель Организационной Зрелости Профессиональных Сервисов (Professional Services Organizational Maturity Model, PSOMM).
Если бы мы смотрели только на слайды, то могли бы прийти к довольно быстрому и простому выводу — на каждом уровне есть соответствие:
- «Начало: создание кода» будет напрямую соответствовать 1-му уровню зрелости.
- «Фокус на ценности» — уровень Agile Fluency с одной звездой, по-видимому, соответствует уровню зрелости 2. Появляется способность распознавать клиента и ценность для клиента становится предметом работы, а также синхронизирует людей и команды на основании запросов клиента. Есть непрерывность процесса и элементов, которые ему сопутствуют. Подразумевается изменение культуры, направленное на то, чтобы быть более ориентированным на внешний мир и осознать, что существует клиент и концепция ценности клиента, которую можно уловить при определении запросов клиентов.
- «Поставка ценности» с 2-мя звёздами, по-видимому, соответствует уровню зрелости 3, потому что команда может создавать ценность в соответствии с ритмом рынка, и это звучит как «постоянство результата». Также подразумевается, что есть значительный рост навыков, чтобы обеспечить постоянство результатов.
- «Оптимизация ценности» с 3-мя звёздами в модели Agile Fluency, кажется, соответствует уровню зрелости 4, где основное внимание уделяется оптимизации экономических результатов и извлечению реальной выгоды для бизнеса от возможностей, достигаемых на более низких уровнях Agile Fluency.
- «Оптимизация для системы» с 4-мя звёздами в Agile Fluency Model, по-видимому, напрямую соотносятся с концепцией оптимизации организации и её возможностей по предоставлению сервисов и продуктов на уровне зрелости 5. Итак, вот оно, простое сопоставление один к одному!
Если бы это было так просто! Я считаю, что требуется более глубокий анализ. Я действительно считаю, что модель Шора и Ларсен по существу аналогична пяти уровням зрелости и что нам следует принять сопоставление один к одному за чистую монету. Однако требуется более глубокий анализ и осознание, чтобы увидеть пробелы, не просто с целью «докопаться», а для того чтобы создать практические, прагматичные, действенные рекомендации по совершенствованию и продвижению вверх, независимо от того, считаете ли вы это Agile Fluency или организационной зрелостью.
Проблема с «Ценностью»
Вероятно, я был первым членом Agile-сообщества, который написал что-либо по существу на тему «ценности» и оптимизации экономических показателей с помощью Agile-методов в форме книги из 63 000 слов, опубликованной в 2003 году. В то время Agile-сообщество не сильно интересовалось такими темами, как «определение приоритетов невыполненных итераций на основе ценности», поэтому моя заявка на конференцию Agile-2003 была отклонена. Самое современное на тот момент представление в сообществе экстремального программирования заключалось в том, чтобы определять приоритеты на основе технического риска. Agile был в значительной степени внутренне ориентированным движением. Да, в Манифесте Agile упоминалось о «ценности», но когда дело дошло до практического руководства, то её просто там не оказалось. В то время, когда я писал «Agile-менеджмент», я думал, что определить «ценность» легко.
Я был одержим литературой по оптимизации производственных процессов, такой как «Теория ограничений», и был убеждён, что всё, что нам нужно сделать, это определить ценность функций, а затем использовать эту информацию для определения приоритетов и, следовательно, оптимизации экономических показателей. Сейчас, 13 лет спустя, я могу сказать вам, что я менее уверен чем когда-либо, что мы знаем, как определить «ценность» каким-либо значимым способом, чтобы впоследствии это могло привести к детерминированному подходу по оптимизации экономических показателей.
Что означает «ценность»? Если вы прочитаете текст статьи Шора/Ларсен, то он подразумевает довольно простую концепцию: «Представляет ли эта история ценность для наших клиентов?». Ответить на этот вопрос довольно просто. Поэтому, если мы примем это на таком уровне, мы сопоставим с уровнем организационной зрелости 2: мы можем идентифицировать клиента; и мы понимаем, что может представлять значимую ценность для этого клиента; мы способны отсеивать задачи и другие элементы внутренней ценности, которые не имеют значения для клиента. Таким образом, наблюдается некоторое улучшение в согласовании и единстве целей.
У нас есть клиентоориентированность. Последователи Канбан Метода признают некоторую синергию с ценностями и принципами Канбан. «Проблема с ценностью» начинается, когда вы пытаетесь выйти за рамки понятия «является ли это ценным» и вместо этого пытаетесь количественно оценить ценность. В 2003 году я посвятил две главы книги «Agile-менеджмента» попыткам разобраться с этим. Честно говоря, в большинстве случаев вывод был бы таков: профессиональная сервисная работа не может быть сведена к количественной оценке ценности, в лучшем случае её можно свести к многомерной качественной оценке. Теперь я преподаю этот метод оценки в качестве учебного занятия от 1 до 1,5 дней в рамках мастер-класса по Канбан-коучингу в учебных программах по ESP.
Если мы посмотрим на определения Agile Fluency от 2-х до 4-х звёзд, то подразумевается, что нам нужен более сложный подход к определению и пониманию ценности. В оригинальной статье (при условии, что она датирована 2012 годом) заявляют, что эта проблема решена в Lean Startup или в Бережливой разработке ПО. Честно говоря, это нереально. Lean Startup поможет вам проверить гипотезу о том, что ценность может существовать. Я действительно не знаю ничего в области бережливой разработки ПО, что даёт конкретное представление об анализе ценности. Тем не менее, совокупность знаний по Бережливой разработке в книгах Райнертсена или Кеннеди, предоставляет некоторые методы. Стало довольно модным определять стоимость, используя варианты подхода Рейнертсена к «стоимости задержки». Я всё ещё считаю, что этот материал находится на начальной стадии и имеет проблемы, а анализ того, почему это так, является предметом ещё одной продолжающейся серии статей на этом сайте, которая началась со статьи «Что мы знаем о продолжительности: Часть 1».
Таким образом, переход от Agile Fluency к 2-звездочному уровню подразумевает, что нам нужны лучшие способы определения ценности. У нас есть некоторые методы для этого в базе знаний Канбан с 2007 года — например, качественная оценка стоимости задержки и присвоение классов сервиса рабочим элементам. Это согласуется с моим анализом того, что Канбан-система и доски могут вывести вас на 4-й уровень организационной зрелости, как описано в моей статье «Паттерны Канбан и организационная зрелость». Метод оценки рисков, который я сейчас формализовал в учебных планах ESP, вместо того, чтобы пытаться объединить его с Канбаном (как мы делали с 2009 по 2014 год), обеспечивает комплексный, хотя и, по общему признанию, качественный, сложный и недетерминированный метод как для оценки стоимости, так и для выбора, упорядочивания и планирования с использованием оценки стоимости. Большая часть этой работы была доступна публично в 2012 году, хотя она и не представлена в удобной книге, но значительная её часть появилась в моём выступлении на конференции Agile 2009.
Проблема с «Канбаном»
Читая статью про Agile Fluency, мы должны признать, что, когда Шор и Ларсен говорят «Канбан», они на самом деле имеют в виду «Командный Канбан». Это тема, считается настолько тривиальной в Канбан-сообществе, что Kanban University не потрудился преподавать её или иметь определённую учебную программу для неё до 2015 года с введением практикующего специалиста по командному Канбану. В статье «Паттерны Канбан и организационная зрелость» я определяю Командный Канбан как поведение 1-го уровня зрелости. Однако я отмечаю, что бывают случаи, когда одна команда предоставляет узнаваемый и атомарный сервис, а не просто является частью более широкого рабочего процесса, в котором участвуют несколько команд. В случае, когда команда предоставляет сервис и он самодостаточен для этой команды, мы рассматривали бы их как находящихся на уровне организационной зрелости 2, при условии, что рабочие элементы были бы ценными для клиентов.
Из этого анализа мы начинаем видеть размытие границ. 1-звездочная Agile Fluencyможет существовать на уровне организационной зрелости 1. Но по-видимому, существует неявное понимание того, что «команда» предоставляет сервис, ориентированный на клиента. Следовательно, имеется значение уровня организационной зрелости 2, но в небольшом масштабе команды, не включающем более сложный рабочий процесс. Возможно, даже существует более неявное предположение, что если бы требовался более длительный и сложный рабочий процесс, то люди с этими дополнительными навыками должны быть привлечены в команду для поддержания её целостности и инкапсуляции в качестве поставщика комплексных сервисов.
Жаль, что Шор и Ларсен, похоже, не знают о Канбане больше и что они предполагают, что Командный Канбан — это всё, что есть. На самом деле, за много лет до 2012 года мы в значительной степени решили, что Командный Канбан был настолько тривиальным явлением, что не стоил наших усилий даже документировать его, не говоря уже об обучении ему. Только в последние годы, когда стало известно, что большая часть рынка находится на уровне организационной зрелости 1, мы решили помочь в начальном освоении, определив Командный Канбан и связанное с ним обучение. В Lean Kanban University, практикующем Командный Канбан, мы не предполагаем уровень зрелости 2. Мы не предполагаем, что команда, работающая с клиентами, обладает всеми кросс-функциональными навыками, необходимыми для предоставления сервисов «под ключ» без зависимостей. Таким образом, для нас Командный Канбан находится на уровне «ниже уровня Agile Fluency».
Повышение технической компетенции
Хорошее согласие получается между моделью организационной зрелости уровня 3 и Agile Fluency с 2-мя звёздами. С помощью Канбан, а также в обучении специалистов по Kanban Management Professional (KMP), в 5 главе пособия «Канбан: Успешные эволюционные изменения для вашего технологического бизнеса», мы рассматриваем способы улучшения. Например, сокращение времени поставки. Модель Шора/Ларсен предполагает, что вы можете сделать это с помощью экстремального программирования, что является вполне обоснованным предположением, но оно сопровождается повесткой, что вы примете Agile-методологию. Канбан — это анти-методология. Это метод «начать с того, что вы делаете сейчас» и развить это. В Канбан мы учим практиков определять возможности для улучшения и внедрять конкретные методы, часто Agile, технические методы, чтобы стимулировать улучшения. Канбан использует улучшения на основе моделей. Он также не предполагает контекст разработки ПО. Независимо от контекста, например, от рекламных агентств или компаний, занимающихся исследованиями рынка, мы ожидаем, что технические компетенции улучшатся, чтобы перейти на третий уровень организационной зрелости.
Проблема с масштабированием
В моделе Agile Fluency с 3-мя звёздами есть стремление оптимизировать экономические результаты. Это явно прямое сопоставление с уровнем организационной зрелости 4. В чём я отличаюсь от Шора и Ларсен, так это в манере и стиле достижения этого. Их предлагаемый подход заключается в том, что вы начинаете добавлять бизнес-функции в команду, и команды становятся всё больше и больше и всё более кросс-функциональнее. Подход Канбан Метода отличается. Мы используем оценку рисков, чтобы обеспечить общий язык для коммуникации, сотрудничества и принятия решений. Мы считаем, что вам не нужно делать команды всё больше и более многофункциональными, чтобы добиться совместной работы. Мы считаем, что сотрудничество проистекает из общего чувства цели, единства, согласованности, общего языка и общей основы для принятия решений. С 2014 года я решил включить это в наш тренинг по ESP, а не рекламировать его как «Продвинутый Канбан», как это было в период 2012—2014 гг. Канбан способен выводить организации на 4-й уровень зрелости с 2007 года и, учитывая предоставленное описание, способен обеспечить 3-звездочную Agile Fluency в течение одного и того же периода времени не только командам, но и целым продуктам или бизнес-подразделениям. У нас уже было справочное тематическое исследование Канбана по проектам с участием более 50 человек в 2007 году. Канбан использовался в организации из 150 человек с годовым бюджетом около 17 миллионов долларов. Мы не играли с «командами», когда дело касалось Agile Fluency
Проблема с оптимизацией
Прочитав описание 4-звездочной Agile Fluency Шора и Ларсен, я согласился, что справедливо будет сказать, что Канбан не показал, что он может достичь всего этого уровня на момент написания статьи в 2012 году. Тем не менее, значительное количество описываемых ими атрибутов присутствовало и сообщалось в Канбан-сообществе и на конференциях Lean Kanban: использование Портфельного Канбана (для балансировки рисков и бизнес-инициатив); использование Восходящего Канбана (для управления продуктами и реальных опционов); Операционные ревью на уровне единицы продукта или бизнес-единицы, демонстрирующие понимание системы систем и того, как каждый независимый рабочий процесс или проект взаимодействовал и зависел от других. Тем более разочаровывает, что Джим Шор появился на одной из наших конференций до появления этой статьи 2012 года, и вокруг него было много таких доказательств, если бы он захотел их увидеть. Сейчас я могу сказать, что я вполне уверен, что целые организации могут достичь 4-звездочной Agile Fluency (и более), используя ESP.
Выводы
Оказалось важным, что я переупаковал множество передовых и периферийных практик Канбана в ESP, потому что слишком многие специалисты по управлению видят или позиционируют Канбан только как метод на уровне команды. Если бы более высокопоставленные руководители, и я включаю в эту категорию Шора и Ларсен из сообщества Agile, действительно потрудились понять Канбан и то, что мы делали в сообществе Канбан за последние 8 лет, то они могли бы понять, что у нас есть много ответов, много проверенных методов, и что большинство из этих концепций дополняют и не угрожают тому, что они уже делают. Канбан и ESP в сочетании с соответствующим внедрением Agile-практик может и приведёт вас к уровню гибкости бизнеса, который Шор и Ларсен называют «желательным». Если у вас есть стремление достичь 4-звездочного уровня Agile Fluency, мы можем доставить вас туда сейчас, в 2016 году. И мы можем сделать всё это, не реорганизуя ваш бизнес в крупные кросс-функциональные команды. Канбан никогда не разделял Agile-повестку кросс-функциональных команд. Мы верим в достижение сотрудничества с помощью других средств — общего языка, прозрачности, наглядности, общих рамок принятия решений, основанных на фактах, методов качественного анализа, которые способствуют достижению консенсуса, ориентации на клиента, единства целей и согласованности.
Я хотел бы поблагодарить клиента, который попросил провести эту оценку и анализ, это было полезное и стоящее занятие.