Как мы организовали работу Agile-коучей в формате сервиса Agile As a Service

Друзья, всем привет!

Сегодня хочу рассказать, как у нас в компании (а это многотысячная организация с большим количеством продуктовых инхаус и аутстаф команд) организован сервис предоставления Agile-услуг. У нас это называется Agile As a Service (далее AaaS). Начну с того, какую проблемы мы решали с помощью Agile As a Service?

Проблема

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

Дополнительные вопросы

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

Рабочая гипотеза

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

Тестирование гипотезы

Для проектирования сервиса принимаем решение использовать инструменты Канбан-метода: воркшоп СТАТИК (о том, как это было сделано, я расскажу в отдельном посте) для проектирования Канбан-системы, Канбан-практики и Канбан-принципы по необходимости.

Получаем следующую визуализацию рабочих процессов двух уровней: уровня команды (рис. 1), то есть ML1 в терминах KMM, и уровня сквозного сервиса (рис. 2), то есть ML2.

Каждая визуализация решает определенную задачу.

Рабочий процесс команды (ML1)

Визуализация для команды нужна нам со вторым Agile-коучем для ежедневных митингов по задачам из дорожной карты. Это большие запросы на улучшение продуктовых команд. На этой доски мы видим не сами запросы, а шаги их выполнения, декомпозированные до уровня простых задач с коротким временем выполнения. У нас это тип «Коучинг». Так мы понимаем, что наш основной бизнес – улучшение продуктовых команд – выполняется и имеет результат.

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

Почему это уровень ML1?

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

Сквозной рабочий процесс команды (ML2)

Визуализация сквозного сервиса нужна для управления потоком работы на уровне улучшения продуктовых команд. Заказчики этого сервиса – директора Блока ИТ.

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

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

Почему это уровень ML2?

На данном уровне мы не принимаем самостоятельных решений, что брать в работу в дорожке «Продукты и сервисы в дорожной карте». Эта ёмкость забронирована за Блоком ИТ.

Как мы получаем заказы в сервисе?

Сотрудники обращаются к нам по e-mail, через корпоративный мессенджер или лично. Все обращения мы фиксируем в виде карточек в колонке «Возможности» и дальше уже по мере проработки и готовности они попадают на доску или остаются без внимания.

Где мы описываем правила работы сервиса?

Явные правила описаны и доступны к корпоративной Wiki.

Как мы следим за сроками?

С теми типам запросов, где у нас установлена фиксированная дата поставки (как правило это Консультация или Фасилитация мероприятия), мы используем поле Due Date (рис. 5), которое явно на карточке подсвечивает нам срок выполнения запроса.

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

Как мы следим за заблокированной работой?

Для этого мы используем поле Flagged (рис. 6) и проставляем в нем признак Impediment. Это позволяет нам собрать статистику по причинам и времени блокировки.

Кроме этого, мы проставляем в комментарии причину блокировки.

Как мы следим за тем, что не перегружены?

Для этого мы используем персональные WIP-лимиты (рис. 7) как на командной доске, так и на доске с улучшениями продуктовых команд.

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

Метрики сервиса Agile As A Service

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

1. Списание времени.
2. Количество поставленных в срок улучшений в продуктовых командах (тип запроса «Эпик»).

Дополнительные метрики – количество других поставленных типов работ от Владельцев продуктов и Технических лидов:

1. Консультации.
2. Фасилитации мероприятий.

Метрики, за которыми слежу я, как руководитель сервиса:

1. Персональный WIP-лимит, как защита от перегрузок.
2. Улучшения сервиса.
3. Учебные материалы, как шаринг знаний по Agile в группе компаний.

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

Результат

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

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

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

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

Если у вас остались вопросы, приходите к нам на консультации. Мы подробно ответим на них и подскажем, что вам делать в вашем контексте.