А что, если проблема не в команде, а в невидимости?
Команда XIT в Microsoft тонула. Время выполнения запросов — 155 дней. Бэклог рос бесконтрольно. Руководство не давало денег. Со стороны казалось: команда работает плохо.
Но Драгош Думитриу, менеджер программ, заметил странное: инженерная работа по каждому запросу занимала в среднем 11 дней. Не 155, а 11. Куда девались остальные 144 дня? Они растворялись в ожидании — в очередях, согласованиях, передачах между отделами. Работа была невидимой, а значит — неуправляемой.
Дэвид Андерсон помог Драгошу сделать простую вещь: нарисовать поток работы. Не внедрить новый фреймворк, не переучить людей, не реорганизовать отдел. Просто визуализировать, где задачи проходят, а где стоят. Это и стала первая Канбан-система в Microsoft.
Результат за 15 месяцев: целевое время выполнения — 25 дней вместо 155. Координационные издержки упали настолько, что регулярные созвоны стали не нужны — система автоматически уведомляла, когда в очереди освобождалось место, и оно заполнялось за два часа. Без аджайл-коучей, ретроспектив и борьбы с сопротивлением.
Вот что в этом кейсе цепляет. Джефф Сазерленд описывает, как в те же годы Microsoft яростно сопротивлялся Scrum — первые попытки воспринимались как «инфекция», которую нужно уничтожить. Scrum требовал менять структуру, роли, культуру — и вызывал иммунную реакцию организации. Канбан в XIT сработал ровно потому, что ничего этого не требовал. Методология PSP/TSP была прописана в контракте, менять её было невозможно. Андерсон не стал бороться с ограничениями — он сделал их частью решения.
Мы часто ищем серебряную пулю в новых методологиях. А ответ бывает проще: покажите людям, где застревает работа, — и они сами разберутся, что делать.
📚 Источники: • Дэвид Андерсон — «Канбан. Альтернативный путь в Agile» • Джефф Сазерленд — «Scrum. Революционный метод управления проектами»
