Данная статья является продолжением цикла публикаций о прото-Канбан системах.
Что такое агрегированный командный Канбан
Агрегированный командный Канбан – прото-Канбан система уровня зрелости 3 из KMM. Данному уровню зрелости соответствует:
- устойчивый процесс
- устойчивые результаты
- попадания в ожидания заказчиков
- соответствие цели заказчиков
- неустойчивая экономика (сервиса)
Для чего нужен
Последняя в списке, но не по значению, форма прото-Канбана – агрегированный командный Канбан. Еще один очень часто встречающийся на практике дизайн канбан-доски.
Данная форма прото-Канбана очень популярна в силу своей гибкости. Она может эволюционно появится из командного Канбана с постоянным WIP-лимитом.
Агрегированный командный Канбан можно использовать как практику перехода с уровня зрелости ML2 на уровень ML3 .
Как устроен
Процесс перехода может быть следующим: руководитель сервиса (или чаще агент изменений) хочет визуализировать весь рабочий процесс от начала до конца, но еще не обладает достаточным влиянием на все вложенные сервисы и не может объяснить необходимость установить лимиты на всех этапах.
Поэтому он может предложить общую визуализацию всего процесса, когда в команде разработки WIP-лимиты установлены, потом бесконечная очередь перед тестированием, потом снова WIP-лимит в тестировании и потом опять бесконечные очереди на этапе внедрения.
Данная форма прото-Канбана очень важна для формирования полноценной вытягивающей системы. Когда люди начинают видеть весь путь, который проходит работа от начала до конца, а где-нибудь посередине длинную очередь задач из-за отстутствия лимитов, они быстрее осознают ценность введения ограничения на всех этапах (и даже в очередях). В такой визуализации издержки и потери в бесконечных очередях очевидны.
Пример использования
На рисунке 2 приведен пример агрегированного командного Канбана. В колонке “Аналитика готова” бесконечная очередь, которая образовалась после того, как команда сервиса решила визуализировать весь процесс поставки ценности с помощью первой Канбан практики.
Ранее данная колонка была “Бэклогом продукта” для команды разработки, куда входили только разработчики и тестировщики. Аналитики не входили в состав скрам-команды. Они готовили элементы бэклога продукта для разработчиков прямо в бэклоге продукта.
Из-за того, что им приходилось работать на два фронта (готовить элементы к работе, а потом объяснять внутри спринта разработчикам, как их реализовывать), они испытали очень сильный стресс и перегрузки и даже попросили себе отдельный спринт, чтобы их не разрывало на части.
После визуализации всего пути поставки стало ясно, что в данном процессе две бесконечные очереди: очередь на то, что нужно сделать аналитикам, и очередь на то, что нужно сделать разработчикам. Фактически это были две отдельные команды.
Визуализация агрегированного командного Канбана помогла команде сервиса вместе с руководителем осознать, что задачи после анализа скапливаются в бесконечной очереди и по большей части не делаются. Поэтому команда не может гарантировать руководителю понятных сроков по всем задачам в этой колонке, а руководитель не может строить уверенные квартальные планы релизов и отчетов перед руководством банка.
После осознания проблемы команда аналитиков вместе с руководителем стала систематически чистить очередь готовых к разработке задач, чтобы привести объем задач в этой очереди в какому-то реальному числу, который можно сделать за приемлемое время.
Заключение
Агрегированный командный Канбан является одной из практик перехода с уровня зрелости ML2 на уровень ML3.
Агрегированный командный Канбан позволяет увидеть бесконечные очереди между командами и взять их под контроль.
Требуется большой уровень доверия к агенту изменений, чтобы внедрить WIP-лимиты на всех этапах поставки задач и закрепить уровень зрелости ML3 для данного сервиса.
Подробно эта форма прото-Канбан системы разбирается на онлайн-тренинге Team Kanban Practitioner.
На этом у меня по теме прото-Канбана всё, дорогие друзья. Было приятно поделиться с вами не только теорией, но и практикой применения форм прото-Канбана.
Об ограничениях прото-Канбана я рассказывал в первой статье. Пожалуйста, помните об этом. Хорошего вам, устойчивого сервиса для клиентов и надежных экономических показателей.
С вами был Игорь Филипьев, руководитель школы Канбана.
За ревью спасибо Евгению Степченко (Telegram – @StepEv).
Интересует корпоративное обучение и консалтинг по Канбану?
Пишите нам на school@filipyev.ru.