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

Сегодня я хочу рассказать, чем закончилась история с Канбаном на двадцать семь человек.

Часть 1. Сначала к выводам

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

1. Я совершенного ничего не знаю о Канбане.
2. Все, что я знал до этого, оказалось не так.

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

Роль Service Delivery Manager

Ошибка первая — самая большая — это неправильное понимания роли Service Delivery Manager (далее SDM). Раньше я полагал, что эта роль — некий аналог роли скрам-мастера из фреймворка Scrum. Но позже на практике и после консультации я убедился, что это роль менеджера. Самая настоящая руководящая роль.

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

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

В Канбане есть еще одна роль — Service Request Manager (далее SRM) или менеджер сервиса запросов. Эта роль работает в паре с SDM. Если между ними партнерские отношения, то с высокой долей вероятности будет качественный уровень взаимодействия сервиса запросов с сервисом поставки. А вот если в каком-то из сервисов роль отсутствует, второй роли придется залезать в «чужой» огород и исправлять ситуацию (если она конечно же «горит душой» за дело).

В первом посте я описал руководителя бизнес-команды. Она — прекрасный образец роли SRM. Но из-за того, что я всё время фейлил выполнение роли SDM, она не находила поддержки и партнерства в сервисе поставки и из-за этого фактически работала на два сервиса. Вероятно, ей было тяжело (хоть она и не признавалась); она всегда честно и открыто говорила о том, что ей не хватает менеджера со стороны IT.

Каденции

Третьей ошибкой было некорректное понимание сути каденций. В посте с провалом я описывал, что встречи на двадцать человек казались мне жутко неэффективными, и я задавался вопросом, как же масштабировать Канбан, минуя ограничение в 7-9 человек, и при этом сохранять гибкость?

Оказалось, что командных каденций в Канбане ровно одна — ежедневный канбан-митинг. Все остальные каденции — менеджерские. Как вам это нравится? МЕ-НЕ-ДЖЕР-СКИЕ! И точка. То есть на встречи по наполнению очереди сервиса поставки (когда сервис поставки принимает на себя обязательства поставить софт, а сервис запросов обязуется принять поставленное), на планирование поставки (когда происходит передача готового к поставке софта запросу), на обзор сервиса ходят менеджеры. SDM, SRM, представители команды при необходимости, но отнюдь не вся команда.

И еще, обзор сервиса — это не аналог ретроспективы. Это именно обзор сервиса с обсуждением таких метрик, как накопительная диаграмма потока (CFD), контрольная диаграмма, диаграмма распределения времени выполнения и так далее. А ретроспектива — она с другими целями и для другого. Так что будьте готовы работать с менеджерами на этих каденциях.

Роль Скрам-мастера

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

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

Менеджмент

Напоследок хочу поразмышлять о важности слова «management» в Канбане и о модном тренде на самоорганизацию. Если мы посмотрим на обучение Канбан-методу, мы найдем слово «менеджмент» в названии тренингов, посвященных дизайну канбан-систем — Kanban Managment Professional I — и каденциям — Kanban Managment Professional II.

Четвертой ошибкой было исключение данного слова из зоны внимания и концентрация только на самоорганизации команды. Следствием стало полное игнорирование важности хоть какой-бы то ни было менеджерской активности в команде и нежелание делать одну очень важную вещь, когда команда заходит в тупик — брать на себя ответственность за происходящее. Иными словами: «Let’s do something about it». Я боялся, что менеджерское влияние (читай «эго») убьет инициативу и самоорганизацию в команде.

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

Я понимаю, что именно сегодня нам, как никогда, нужны хорошие, опытные менеджеры в IT, чтобы выровнять перекос, вызванный повальной «самоорганизацией» без понимания, как ее вводить. Как сказала руководитель из бизнеса: «Да у нас этой самоорганизации хватает. У нас ее с избытком. Взять хотя бы автотесты на cucumber, которые разработчики написали сами, чтобы помочь тестировщикам. Нам менеджер нужен!».

Часть 2. А теперь, чем же всё закончилось

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

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

Рекомендации

Напоследок хочу дать ряд рекомендаций.

1. Посещать тренинги по Канбану.
2. Читать книги по Канбану.
3. Описывать кейсы, задавать вопросы, обмениваться опытом в канбан-комьюнити.*

* — обязательно. Именно описание кейса в сообществе и вопросы по нему помогли мне найти ответы и сформировать следующие шаги в решении проблемы.

Удачи, друзья!