Канбан — это Agile или нет?
1) Почему вокруг вопроса столько споров
Сама формулировка “Kanban — это Agile?” часто ломается о то, что люди вкладывают в слово Agile разные значения:
- Agile как набор ценностей и принципов (мышление, культура, способ принятия решений).
- Agile как семейство методов (Scrum, XP, Kanban, Crystal и т.п. — как ярлыки, по которым компании себя называют).
- Agile как “ритуалы” (спринты, дейлики, ретро) — самый распространённый, но самый неточный взгляд.
Когда спорят люди из разных “словарей”, получается классическое: один доказывает про ценности, другой — про происхождение, третий — про практики. Поэтому корректнее отвечать так:
Канбан может быть Agile-подходом по сути, но не обязан им быть по форме.
2) Две вещи, без которых Канбан не Канбан
Чтобы дальше не путать понятия, важно разделить:
- Kanban-доска (визуализация задач)
- Kanban-метод (управление потоком + ограничения + обратная связь + улучшения)
Доску может вести любая команда в любом стиле, даже в классическом “водопаде”. Это ещё не делает процесс Agile. Канбан-метод начинается там, где команда использует доску как инструмент управления потоком и контроля незавершённой работы.
В книге прямо подчёркивается ключевой механизм: Kanban требует ограничивать НЗР (незавершённую работу) и экспериментировать с настройками процесса, наблюдая влияние на время выполнения, качество и предсказуемость.
3) Критерий “Agile-ности” без привязки к названию
Если отбросить ярлыки, можно проверить любой подход на признаки, которые обычно и делают работу Agile:
Признак A: короткая цепь обратной связи
Команда регулярно получает сигнал “мы делаем правильное?” и “мы делаем это правильно?” и меняет курс на основе фактов.
В Kanban это часто обеспечивается метриками реального времени: например, lead time (среднее время ожидания/прохождения) и видимость узких мест прямо на доске.
Признак B: pull вместо push
Работа вытягивается командой по готовности, а не “проталкивается” извне без учёта пропускной способности. В книге это прямо связывается и с Lean (JIT), и с Agile-практиками: команда сама выбирает, когда и сколько работы брать.
Признак C: управление незавершённой работой
Меньше начатого — больше законченного. WIP-лимиты снижают переключение контекста и вскрывают пробки.
Признак D: адаптация к изменениям без разрушения системы
Условия поменялись — приоритеты корректируются так, чтобы система продолжала работать, а не рассыпалась от “срочного”.
В книге отмечено, что Kanban обычно позволяет реагировать быстрее, чем Scrum, что соотносится с ценностью Agile “реагирование на изменения важнее следования плану”.
Если эти признаки есть — по сути это Agile-способ работы, даже если никто не произносит слово “Agile”.
4) Аргументы “Канбан — это Agile”
Здесь важно не “к какому лагерю относить”, а почему он считается Agile многими практиками.
4.1 Kanban соответствует важным принципам Agile
Книга прямо говорит, что Scrum и Kanban “достаточно хорошо вписываются” в ценности и принципы Agile, приводя примеры: pull/JIT, Kaizen, реагирование на изменения.
То есть по “сердцевине” (адаптация, эмпирика, быстрая обратная связь) Kanban ведёт себя как Agile-подход.
4.2 Kanban создаёт прозрачность и управляемость потока
Узкие места видны не “по ощущениям”, а буквально на доске: колонка переполнена — следующая пустая. Это превращает управление работой из разговоров в наблюдаемую систему.
4.3 Kanban встроенно поддерживает непрерывные улучшения
И Scrum, и Kanban — эмпирические: вы меняете процесс, смотрите, что получилось, и меняете снова. Книга подчёркивает саму идею цепи обратной связи и экспериментов с процессом (в том числе через WIP-лимиты).
Это очень “Agile” по смыслу: улучшать способ работы на основе фактов.
5) Аргументы “Канбан — не Agile”
Такая позиция тоже не взята с потолка — она обычно опирается на два тезиса.
5.1 Канбан исторически сильнее связан с Lean, чем с “Agile-брендингом”
Многие воспринимают Kanban как продолжение Lean/теории ограничений/потокового мышления. В книге даже есть отдельный акцент на Kaizen и JIT — классические Lean-опоры.
Отсюда позиция: “Kanban — Lean, а Agile — другое”. Практически же в продуктовой разработке Lean и Agile часто переплетены, поэтому спор обычно терминологический.
5.2 Kanban накладывает меньше ограничений и не задаёт “упаковку” процесса
Scrum более директивен: роли, спринты, обязательные события. Kanban задаёт меньше “обязательных элементов”, оставляя больше параметров настройки.
Если человек считает Agile = “итерации + церемонии + роли”, тогда Kanban действительно кажется “не Agile”.
5.3 Канбан можно внедрить как инструмент контроля, а не как способ обучения
Это ключевой практический контраргумент:
можно повесить доску, заставить всех таскать карточки, увеличить отчётность — и получить “псевдо-Канбан”, который не про самоорганизацию и улучшения, а про контроль.
Такой процесс может выглядеть современно, но по сути будет далёк от Agile.
6) Нормальная формулировка без лагерей
В реальной практике чаще всего работает такая рамка:
- Kanban-метод совместим с Agile-мышлением и часто применяется как Agile-подход.
- Kanban-доска сама по себе не делает работу Agile.
- Kanban можно использовать в не-Agile культуре, если цель — только видимость и контроль, без эмпирики и улучшений.
То есть вопрос не в названии, а в том, как именно применяется.
7) Scrum и Kanban как два разных “двигателя” обратной связи
Оба подхода эмпирические, но “двигают” изменения по-разному.
7.1 Scrum: обратная связь через фиксированные итерации
Спринт — главный ритм: планирование → выполнение → обзор → улучшения.
7.2 Kanban: обратная связь через поток и метрики реального времени
Kanban даёт возможность настроить цикл улучшений под частоту анализа метрик: слишком длинный цикл — улучшения идут медленно; слишком короткий — процесс не успевает стабилизироваться.
На практике это означает: Kanban часто удобнее там, где работа “неровная” и приоритеты меняются постоянно.
8) Ситуации, где Kanban почти всегда “заходит” быстрее Scrum
Есть тип работ, где Kanban обычно легче внедряется и быстрее даёт эффект:
8.1 Поддержка, инциденты, операционная разработка
Когда приоритеты действительно меняются ежедневно, обещание “не менять план внутри спринта” становится нереалистичным. В книге описан кейс, где менеджеры выбирают Kanban как логичную отправную точку именно потому, что приоритеты менялись каждый день, и спринты “не очень подходили”.
8.2 Много входящих задач разного типа и размера
Kanban позволяет явно настроить классы работ (пути на доске, правила выбора, SLA-логика), не ломая всё под одинаковый таймбокс.
8.3 Несколько команд на общей доске
В книге отмечено, что формат ежедневной встречи в Kanban часто более “доско-ориентированный” (фокус на узких местах), и это масштабируется лучше, когда несколько команд смотрят на общий поток.
9) Ситуации, где Scrum чаще даёт более быстрый порядок (особенно для новичков)
Kanban оставляет больше свободы и требует зрелости в управлении процессом. Scrum, будучи более директивным, часто помогает командам, у которых ещё нет дисциплины:
- научиться планировать и фиксировать цель короткого периода;
- договориться о “готово” и критериях качества;
- выстроить регулярные точки синхронизации.
В книге прямо говорится: Kanban накладывает меньше ограничений, даёт больше ручек настройки — это может быть плюсом или минусом в зависимости от ситуации и знакомства с инструментом.
10) Гибриды: Kanban внутри Scrum и Scrum-ритм поверх Kanban
В жизни команды часто приходят к смешанным моделям — не из моды, а из прагматики.
10.1 Kanban-подход к бэклогу в Scrum
В книге упоминается, что и для Product Backlog в Scrum можно применять Kanban-подход: ограничивать размер и задавать правила приоритизации.
10.2 От коротких итераций к отказу от таймбокса
Есть интересная мысль: когда итерации становятся всё короче, команда по сути приближается к Kanban; если речь заходит об итерациях меньше недели, можно отказаться от фиксированных итераций.
Это не “правильно/неправильно”, это способ подобрать механизм обратной связи под контекст.
11) Быстрый тест: “У нас Kanban как Agile или просто доска?”
Можно проверить по пяти вопросам. Если на большинство ответ “да”, то Kanban у вас живёт как Agile-подход.
- Есть ли явные WIP-лимиты хотя бы на одном этапе?
- Есть ли правила “как работа попадает в систему” и “как выбирается следующая”? (политики выбора)
- Смотрите ли вы хотя бы раз в 1–2 недели на lead time / cycle time / узкие места и меняете процесс на основе данных?
- Обсуждает ли команда ежедневную работу “от доски” (что застряло, где пробка), а не делает по кругу статус-отчёты?
- Появляются ли регулярные улучшения процесса, а не только “выполнение задач”?
Если ответы “нет”, то чаще всего это “доска задач”, а не Kanban-метод, и вопрос “Agile это или нет” становится бессмысленным — потому что нет главного: эмпирики и улучшений.
12) Частые ошибки, из-за которых Kanban перестаёт быть Agile по смыслу
Ошибка A: WIP-лимитов нет, потому что “мы и так справляемся”
Тогда доска перестаёт выявлять пробки и превращается в каталог задач.
Ошибка B: “Срочное” не ограничено
Когда expedite-поток бесконечный, система всегда будет в режиме пожара. Agile-поведение тут не появляется: команда не учится, а выживает.
Ошибка C: Метрики не используются для изменений
В книге подчёркивается ценность метрик реального времени и выбор длины цикла обратной связи под частоту улучшений. Если метрики смотрят “для отчёта”, ничего не меняется.
Ошибка D: Канбан внедряют как “самый мягкий способ ничего не менять”
Иногда Kanban выбирают, чтобы избежать тяжёлых организационных разговоров: о приоритетах, ответственности, ожиданиях стейкхолдеров. Тогда доска появляется, а поведение остаётся прежним.
13) Так “это Agile или нет?” — корректный ответ, которым можно пользоваться в компании
Можно формулировать так (без философии и без споров):
- Kanban — это метод управления потоком.
- Он совместим с Agile и часто используется как Agile-подход, потому что поддерживает pull, эмпирические улучшения и адаптацию к изменениям.
- Если Kanban используется как система обучения и улучшений — это Agile по сути.
- Если Kanban — только доска и контроль — это не про Agile, даже если выглядит похоже.
14) Мини-план, как сделать Kanban “Agile по сути” за 2–4 недели
Без больших реформ, только практические шаги.
- Нарисовать реальный workflow, а не “To Do / Doing / Done”.
- Поставить WIP-лимит на самый проблемный столбец (там, где очередь).
- Ввести короткую ежедневную синхронизацию “от доски”: что застряло, что закрываем сегодня, где пробка.
- Начать смотреть lead time и фиксировать узкие места как основу для улучшений.
- Раз в неделю выбирать 1 изменение процесса и проверять, что оно поменяло в потоке.
Так Kanban становится не “стеной с карточками”, а машиной обратной связи — а именно это и роднит его с Agile.
Если хочешь, могу сделать две дополнительные версии этой темы в другом формате (без дополнительных вопросов):
- “10 мифов о Kanban и Agile” (миф → что на самом деле → как проверить на практике)
- “Kanban vs Scrum: выбор подхода по типу работы” (таблица ситуаций + рекомендуемая конфигурация процесса)