Метрики Agile-трансформации

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

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

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

Процессная деятельность команд связана с набором метрик, некоторые из которых иногда переезжают в цели Scrum-мастеров (SM), Agile-коучей (АК) и лиц, находящихся над ними.

Можно ли оценивать Agile-специалистов по Lead Time, Velocity, и прочим подобным метрикам?

Если коротко: да (но есть нюанс). И нюанс этот в том, что упомянутые метрики - это метрики команд разработки, но не Agile-специалистов.

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

Таким образом можем наблюдать ситуацию, когда:

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

Какие метрики для Agile-подразделения вашей организации являются общими с командами, а какие - самостоятельными?

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

В некоторых организациях «меню сервисов» Agile-специалистов предлагает десятки пунктов разнообразных активностей. Однако то, что принято называть «Agile-трансформацией» предполагает работу со всего тремя артефактами: Правилами, Инструментами и Обучением.

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

Под Инструментами понимаются таск-трекеры, дашборды и графики, информационные витрины, иные учетные системы и т.п.

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

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

Помимо разделения Agile-деятельности на три артефакта, необходимо отметить и три состояния, в которых данные артефакты могут пребывать: это разработка, доставка и поддержка.

В первую очередь, Правила, Инструменты и Обучения проживают стадию Разработки, т.е. этап от идеи до готовности к распространению (тиражу или внедрению).

После Разработки наступает стадия Доставки до команд:

После этого наступает этап Поддержки:

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

В каких активностях задействованы ваши Agile-специалисты?

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

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

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

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

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

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

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

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

Как в вашей организации выстроен процесс контроля консистентности информации?

Общей визуализацией измерения этапов (Разработка-Доставка-Поддержка) будет следующая схема:

Важно определить показатель (для каждого из трех артефактов - свой), который будет изменяться (расти) на этапе Доставки, и состояние которого будет отслеживаться на этапе Поддержки.

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

Стоит отметить, что далеко не все Правила, Инструменты и Обучение разрабатываются внутри организаций, в которых потом используются. Фреймворки (Scrum, SAFe, LeSS и т.д.) ровно как и обучение по ним часто являются продуктами сторонних компаний. Разработка таск-трекеров (Jira, Trello и т.п.) - также часто происходит на стороне (что не отрицает того факта, что все больше компаний в РФ переходят на свои фреймворки и таск-трекеры).

Для этапов Доставки и Поддержки метрики разнятся в зависимости от Артефактов, к которым они относятся.

Доставка Правил — это не просто их публикация в корпоративном wiki. Речь о полноценной реализации в двух связанных средах:

Фактически, Доставка Правил превращает абстрактные принципы в рабочие механизмы компании. Пропуск этого шага приводит к классическому «у нас Agile только на бумаге» — когда правила есть, но никто не понимает, как их использовать.

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

Величину доставки правил можно измерить с помощью двух простых показателей:

Нужно ли отражать/учитывать ВСЕ понятия? Не обязательно. Здесь важно руководствоваться здравым смыслом и учитывать приоритеты и риски.

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

Доставка Инструментов предполагает тираж разработанных (в организации или на стороне) систем.

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

Так как часто внедряемые инструменты заменяют собой прошлый привычный инструментарий, измерение только роста активных пользователей новой системы может оказаться недостаточным для объективной оценки полноты внедрения. Важно также оценивать и отказ от заменяемых инструментов (например, отказ от ведения задач в Excel в пользу Jira).

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

Таким образом, ключевыми показателями Доставки Инструментов являются рост MAU/DAU, а также ряд дополнительных показателей (описанных выше), помогающих всесторонне оценивать картину происходящего для избежания ситуации «мнимого внедрения».

Доставка Обучения (т.е. доставка знаний до целевой аудитории) измеряется процентом обученных от общей целевой аудитории.

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

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

Обратите внимание, что определение периметра целевой аудитории может оказаться не самой простой задачей: реализовать добровольную аттестацию знаний не только у новичков, но и у «старожилов» компании - активность во многом около-политическая, и требует вовлеченности и поддержки высокого начальства.

Поэтому для более полного измерения процесса Доставки Обучения возможно добавление еще одной метрики: процент сотрудников (в рамках роли) с известным (измеренным) уровнем компетенций. Эта величина поможет в планировании активностей по проведению аттестации знаний, а также проведению непосредственно обучения.

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

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

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

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

Поддержка обучения

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

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

Несмотря на то, что на уровне организации наиболее интересен итоговый результат (ROI), часто измерение эффекта не поднимается выше сбора обратной связи от обучаемых (CSI/NPS и т.п.).

Это может быть связано с рядом причин:

На этапе Поддержки Инструментов метриками служат две величины: охват аудитории инструмента (MAU/DAU), а также удовлетворенность предлагаемого решения (CSI/NPS).

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

Указанные выше метрики валидны и полезны и на этапе Доставки (тиража) инструментов: по изменению MAU/DAU можно отслеживать рост использования, а по состоянию CSI/NPS - мнение пользователей.

Поддержка правил - это не контроль за их соблюдением, а поддержание их актуальности и полезности через:

Таким образом, продолжается мониторинг состояния метрик, рост которых наблюдался на этапе Доставки (т.е. процент правил, реализованных в Обучении и Инструментах).

Более сложным может быть показатель консистентности правил. Измеряется % ключевых правил, которые:

Пример: Корпоративный фреймворк предполагает обязательную роль Владельца продукта. - Роль учтена на HR-портале - Описана в обязательном обучении - Только 30% команд имеют Владельцев продуктов. Консистентность правила = (1 + 1 + 0.3)/3 = 76%

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

Опросы не должны быть частыми и тяжеловесными.

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

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

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

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

Любые правила имеют свой «срок годности» и неизбежно будут нуждаться в актуализации. Поэтому любая попытка обеспечить и сохранить 100% применения на всём периметре организации - это борьба с собственным развитием.

Как в вашей компании устроен процесс Утилизации правил/инструментов/обучения, которые перестали быть актуальными?

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

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

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

Проверка на наличие описанной информации можно считать своего рода реализацией Definition of Ready (DOR), защищающей организацию от лишней работы.

Исходя из того, что подразделение Agile-специалистов само по себе не является в компании зарабатывающим подразделением (за исключением тех, кто оказывает консалтинговые услуги для сторонних организаций), затраты на трансформационные активности можно смело записывать в OPEX, т.е. операционные расходы (а говоря Toyota-языком (TPS) - это чистая Muda, т.е. действия, не добавляющие ценностей конечному клиенту). Таким образом, инвестиция в неэффективные (читай - «ненужные») процессы - это muda в квадрате: затраты, которые не просто не окупятся - они просто бесследно сгорят в костре здравого смысла (как максимум - оставив после себя пепел бесценного опыта).

Именно поэтому крайне важно осознанно подходить к выбору объектов своей деятельности (а иногда и служить фильтром между идеями руководства и ежедневной деятельностью команд). Особенно это относится к Правилам, т.к. Инструменты и Обучение являются ведомыми артефактами.

Как происходит принятие решения о взятии чего-либо в работу в вашем Agile-подразделении?

Привлечение внешних специалистов часто дает буст внутренним процессам. Однако, необходимо помнить про ключевое отличие консалтинговых (приглашенных) специалистов и штатных сотрудников внутреннего Agile-подразделения - разный фокус внимания на описанных выше процессах.

Консалтинг чаще всего сосредоточен на процессе Доставки (Правил-Инструментов-Обучения: либо всего комплекса, либо чего-то конкретного), при этом не решает вопросов Поддержки.

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

Искажение фокусов внимания при внутрикорпоративной деятельности чревато снижением эффективности процессов, что также может привести и к снижение доверия у участников процесса к происходящему.

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

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

Исходя из того, что in-house деятельность шире (и во многом - сложнее) контрактных обязательств внешних специалистов, автор данных строк считает некорректным использовать слово «трансформация» для обозначения enterprise-деятельности Agile-подразделений.

Таким образом, «трансформация» имеет отношения к процессу Доставки, но не всего спектра деятельности, описанного выше.

Ну а отсутствие фокуса на процессах Поддержки порой приводит к псевдо-внедрениям и псевдо-достижениям: новые знания, процессы и инструменты «возводятся» в стороне от реальных рабочих процессов компании.

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

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

Agile-трансформация в крупных организациях — это не разовое изменение, а постоянная работа по адаптации процессов, инструментов и обучения под потребности бизнеса. Её эффективность нельзя измерить метриками команд разработки (Lead Time, Velocity и т. д.), поскольку enterprise-деятельность Agile-специалистов влияет на систему в целом, а не на отдельные команды.

Ключевые выводы:

1. Три артефакта

Agile-деятельность можно разделить на три ключевых направления:

Каждый из них проходит три этапа: разработка, доставка, поддержка.

2. Метрики для каждого этапа

- Для Правил — % их отражения в инструментах и обучении

- Для Инструментов — рост MAU/DAU и отказ от старых решений

- Для Обучения — % сотрудников, прошедших обучение, и соответствие матрице компетенций

- Консистентность правил (используются ли они на практике)

- Удовлетворенность инструментами (CSI/NPS)

- Эффективность обучения (модель Филлипса)

3. Главный риск — несогласованность

4. Agile-подразделение — это сервис, а не трансформация

5. Agile-метрики ≠ командные метрики

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