Попробую на следующей итерации одного из продуктов использовать "IT-канбан" для оперативного контроля внутренней команды, совмещая с "классическим" планированием.
----
В описанном в статье виде, в "IT-канбан" есть те же проблемы, что и в SCRUM: невозможно оценить продолжительность, трудозатраты, цену выдачи, непонятно, в каком состоянии находится проект, сколько (времени, денег, трудозатрат) осталось до выдачи. В таком виде "продать" выдачу инвестору сложно.
Выдавать результаты каждой отдельной задачи? Тоже не очень эффективно, тем более что результаты далеко не всех задач обладают самостоятельной ценностью. И тут возникает вторая проблема: задачи связаны между собой, они могут объединяться и дробиться, причём одни части могут пойти в один столбец доски, другие - в другой.
Тут же становится видна третья проблема: некоторые задачи удобнее выполнять в "пакетном" режиме. Например - согласование и приёмочное тестирование.
Чтобы оставаться на нужном уровне абстракции и количества задач, наверное, в "IT-канбане" имеют смысл только большие и длинные задачи, которых десятки, а не тысячи. Иначе они не поместятся на одной доске. И тут же натыкаемся на четвёртую проблему - внутреннее противоречие: цель "IT-канбана" - в том, чтобы незавершённых задач было как можно меньше, а приходится делать их длинными. И это противоречие граничит с границами применимости "IT-канбана", да и просто agile: небольшие проекты и короткие, не подразумевающие НИР задачи.
Опять же, доверие исполнителям, "всё равно при обычном менеджменте существует только иллюзия контроля". Это при плохом менеджменте. Исполнители бывают разными, и их цели - в т.ч. благие сами по себе цели повышения квалификации и самореализации - могут идти в разрез с проектом. Внутренняя мотивация? Интересных задач на всех не хватает, а получать удовольствие от хорошо сделанной рутины умеют не все. Средней демотивированности рядовой программист на зарплате? "Работа стоит, а срок идёт". Средней ответственности внешний исполнитель? "Ничего, до сдачи работы ещё целая ночь". Возможно, дробить задачи до размера 4-8 часов рабочего времени, и спрашивать о них каждый день - это микроконтроль, но это иногда необходимо. И тут же получается, что даже в небольшом проекте задач - многие сотни, и доска "IT-канбана" для них неудобна.
Кстати, в столбцах доски задач "IT-канбана" нет ячеек с именами людей, не ведётся статистика выполнения задач, не накапливаются исторические данные для будущей оценки и планирования, не видно, что нагрузка ложится на исполнителей неравномерно.
Как и scrum, "IT-канбан" не учитывает выгоды от специализации. Разные люди решают проблемы с разной эффективностью. То, что кто-то по своей воле берётся за задачу, не говорит о том, что он являются самым эффективным её исполнителем. Кстати, к вопросу о том, что повышении квалификации и самореализация могут быть вредными.
----
В общем, IMHO такой "IT-канбан", как и scrum в более-менее чистом виде, похож на очень быстрый и живой бег по сильно пересечённой местности без карты и компаса. Цель известна (но не видна), бежать приятно (пока силы есть), а результат... зависит от везения, количества сил, умения бегать и сложности местности.
Канбан в IT (Kanban Development)