Чем Канбан отличается от Scrum, и причем тут Agile

Scrum, Kanban, а где тут Agile?.. Тем, кто только начинает свое знакомство с гибкими подходами к управлению, бывает непросто разобраться, а в голове остаются только одни названия и путаница, что и к чему относится. В своей статье Василий Савунов, Agile-коуч и эксперт ScrumTrek, решил окончательно расставить все точки над «Ё».

Когда-то давно Скрам и Канбан органично жили под одним брендом Agile. Однако, по мере развития Канбан-метода, его создатели поняли, что он должен базироваться на других принципах, нежели Scrum. Было отмечено, что Kanban-метод не вполне реализует 4 ценности Agile-манифеста, поэтому относить его к Agile-подходам неверно, и надо его из-под «зонтика Agile» вывести.

Примерно в 2015-2017 годах создателями Канбан-метода было принято решение развивать концепцию Business Agility — в противовес понятию Agile. И с этого момента Канбан-метод начал позиционировать себя как альтернатива Agile-подходам, а не их часть.

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

Используйте навигацию, если не хотите читать текст полностью:

→ Разница с точки зрения смысла

→ Разница с точки зрения целей

→ Разница с точки зрения принятия решений

→ Разница в смысле встреч и способе их проведения

→ Разница с точки зрения предусловий

→ Совместимость Kanban и Scrum

→ Примеры применимости Scrum и Kanban

→ Scrum и Kanban на масштабе крупной компании

→ Заключение

Scrum — это готовое руководство о том, как организовать итеративно-инкрементальную разработку нового продукта. Есть даже инструкция, которая называется Scrum Guide. Все элементы Scrum взаимосвязаны друг с другом, и при реализации Scrum нельзя выбросить ничего из того, что указано в Scrum Guide.

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

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

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

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

Можно конечно начать с применения Канбан-метода в отдельно взятом подразделении и улучшить там рабочие процессы, но конечной целью Канбан-метода является улучшение рабочих процессов во всей компании, ради достижения Business Agility.

Kanban. Прежде всего, Kanban-метод — это инструмент менеджмента, то есть он предназначен для руководителей.

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

Scrum — это не инструмент менеджмента, а способ организации рабочих процессов для разработки новых продуктов.

Для ускорения принятия решений и достижения наилучших результатов Scrum делает ставку на командный подход. Чтобы Scrum заработал, нужно вовлечение всех участников Scrum-команды — Владельца Продукта, Scrum-мастера и Разработчиков.

Ответственность за результат коллективная, поэтому управленческие решения принимаются совместно всей Scrum-командой, а не каким-то одним руководителем или менеджером.

Так как Scrum делает ставку на командный подход, то все встречи в Scrum рассчитаны на активное вовлечение всех участников команды и коллективное принятие решений.

Каждая встреча Scrum нацелена на одно из двух:

• или на координацию движения команды (ежедневные митинги, планирование, обзор спринта),
• или на развитие командного взаимодействия, опыта или навыков Scrum-команды (ретроспектива).

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

Канбан-метод смотрит на встречи иначе.

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

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

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

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

По итогу каждой встречи менеджер сервиса получает информацию для дальнейшего улучшения рабочих процессов и принимает управленческие решения.

Чтобы Scrum начал приносить пользу, нужно сделать многое:

— Выделить Владельца продукта — специального представителя бизнеса, который:

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

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

— Выделить Scrum-мастера, который будет заниматься развитием самоорганизации в Scrum-команде.

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

— При необходимости — выделить Scrum-команде свой контур инфраструктуры, чтобы они могли самостоятельно делать end-to-end разработку.

— Обучить основам работы по Scrum всех участников Scrum-команды, заказчиков и все окружение, в котором работает Scrum-команда.

Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера Канбан-методу и сделать первые шаги:

— визуализировать рабочий процесс по вашему сервису;

— сделать соответствующую Kanban-доску;

— разместить на ней все текущие работы;

— проанализировать положение вещей и принять управленческие решения.

Вы можете пойти дальше и использовать другие инструменты Kanban-метода: WIP-лимиты, метрики, управление потоком, каденции и т.д. Но можете этого и не делать. Решение полностью за вами. Когда будете готовы к этому, тогда и используйте.

Может создаться впечатление, что Канбан-метод и фреймворк Scrum совершенно несовместимы, но это не так.

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

Малая команда

Нет смысла пытаться работать по Scrum, когда у вас в команде лишь 1-2 человека, и больше никто не задействован в работе над продуктом. Scrum в такой ситуации будет явно избыточен. Два человека и так легко договорятся, и какого-то специального процесса для этого не требуется.

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

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

Чисто операционная деятельность

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

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

Канбан-метод, при наличии соответствующих инструментов, можно применять и в работе операционистов call-центра. Будут определенные трудности с визуализацией потока входящих звонков, так как частота их поступления весьма велика. Но если это удастся сделать, то у менеджеров call-центра появится возможность собирать данные о статистике обработки запросов от клиентов, и увидеть:

— на каких запросах чаще всего возникают трудности, задержки, затруднения;

— на что нужно обратить внимание, чтобы обеспечить бесперебойное обслуживание потока звонков.

На основе этой информации руководитель call-центра может принять управленческие решения и оптимизировать рабочий процесс.

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

Однако есть и разница.

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

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

Так как у каждой Scrum-команды своя собственная Scrum-доска и свой пул задач, то в процессе совместного движения нужны синхронизирующие встречи (например, Scrum of Scrums или PO Sync), на которые будут приходить представители от команд (Scrum-мастера или Владельцы продуктов). Цель таких встреч — сделать прозрачным для всех текущий статус движения к общей цели, текущие проблемы и подсветить зависимости по которым надо принять решение.

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

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

Некоторые из них — тактические, и проводятся часто (например, ежедневный Канбан-митинг).

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

С другой стороны, на разных уровнях иерархии надо собирать разные данные.

На уровне топ-менеджмента нужны данные о портфолио проектов и о статистике реализации проектов.

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

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

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

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

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

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