Не устанавливать WIP-лимит – это ошибка

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

Некоторые ранние последователи Канбана, например Yahoo! решили отказаться от WIP-лимитов, поскольку считали, что их команды недостаточно слаженны, чтобы справиться с негативными ощущениями, которые лимиты вызовут в компании. Предполагалось, что организации превратятся в более зрелые благодаря средствам визуального контроля Канбана, а WIP-лимиты можно будет внедрить позже. Однако это оказалось непросто, и несколько команд отказались от Канбана, а остальные захлестнула волна реорганизаций и отмен проектов, так что дальнейший сбор данных был затруднен. В Corbis некоторые команды на крупных проектах продолжали работать в рамках Канбана с очень свободными WIP-лимитами над высокоуровневой функциональностью. Результаты вызвали смешанные впечатления.

Я убедился, что напряжение, которое создается при наложении WIP-лимитов на цепочку создания ценности, – это позитивный фактор. Позитивное напряжение вызывает обсуждение организационных проблем и дисфункций. Дисфункции создают помехи рабочему потоку, в результате время выполнения и качество окажутся неоптимальными. Дискуссии и совместная работа, вызванные позитивным напряжением, созданным WIP-лимитом, идут организации на пользу. Это механизм, который порождает культуру непрерывного совершенствования. Без WIP-лимитов улучшение процессов идет очень медленно. Команды, которые сразу же установили WIP-лимиты, сообщают об ускорении роста мощности и организационной зрелости и увеличении коммерческих показателей благодаря регулярным частым релизам высококачественного программного обеспечения. Напротив, команды, пренебрегающие введением WIP-лимитов, обычно сталкиваются с проблемами и демонстрируют лишь незначительные улучшения.