Каденции и синхронизация.

Как известно, в Scrum со спринтом связан ряд встреч: daily scrum, планирование, демо, ретро, а помимо них есть и другие встречи, такие как story mapping для планирования релизов. Все они обеспечивают синхронизацию процесса и взаимодействие со стейкхолдерами. Как легко догадаться, эти функции являются необходимыми для организации потока создания ценности и должны быть выполнены при любом способе организации процесса. В Kanban для выполнения этих функций используются каденции – регулярные встречи, каждая из которых посвящена определенному вопросу и имеет свой собственный ритм, зависящий от соответствующего потока работы.

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

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

– Пополнение списка задач – обсуждение, какие именно задачи сейчас являются наиболее приоритетны и должны быть включены в работу. Обычно раз в 1—2 недели.

– Планирование поставки – представление сделанного и передача результата клиентам

– Обзор качества сервиса и способов его улучшения.

– Операционная встреча по качеству взаимодействия со смежниками.

– Обзор рисков, связанных с блокировками выполнения задач и их влиянием на работу сервиса.

– Обзор и обновление стратегии.

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

Однако, Kanban не диктует, что в процессе обязательно должно быть семь описанных выше серий встреч. Набор конкретных встреч зависит от конкретных условий работы. Например, если команда взаимодействует с разными смежными подразделениями, например, юристами и HR по совершенно разным вопросам и в разном темпе, то это можно обсуждать на разных сериях встреч. Если подразделение предоставляет сервис нескольким разным клиентам с разными циклами поставки, то эти встречи могут проводиться независимо. Более того, далеко не все встречи необходимы. Например, по пополнению может быть принято решение, что каждый стейкхолдер ведет свой список срочных задач, а выбор задач для выполнения происходит по очереди, и специальная встреча назначается, только если этот порядок надо нарушить.

Таким образом, к описанному выше списку стоит относиться, скорее, как к списку важных фокусов, которые, как показывает опыт, стоит держать под контролем тем или иным образом. При этом, что важно, каждый из фокусов надо держать отдельно, и потому смешивать их на одной встрече не слишком желательно, даже если состав участников совпадает. Дэвид Андерсон в своей книге показывает, как эти механизмы возникали в его командах по мере эволюционного развития процесса, и как менялась их форма. Делать это в форме отдельных серий встреч – самый простой способ, но вовсе не обязательный. И в любом случае, встречи появляются постепенно, при чем порядок тоже может быть различен. Подробнее об этом узнать в докладе Алексея Пименова на AgileDays-2018 «Канбан! Что новенького?» В отличие от его доклада на AgileDays-2019, на который я ссылался в начале статьи, этот дает обзор новых техник и рассчитан на более глубокий уровень слушателя.

Масштабирование.

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

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