Так вот, при agile-трансформации большого департамента продаж, состоящего из нескольких отделов, есть два существенно различных варианта, изображенных на схеме. Если у вас в компании стратегией продаж занимается руководитель департамента, который при этом обычно является директором по продажам или занимает аналогичную должность, а руководители отделов лишь организуют работы сотрудников, то директор по продажам становится Product Owner для всех команд, а руководители отделов – скрам-мастерами. А если отделы продаж работали достаточно автономно, например, по сегментам рынка или разным продуктам, и ответственность за выбор направлений по каждому направлению была на руководителях отделов, то именно они могут стать Product Owner, образуя управляющую продажами команду в стиле Scrum of Scrum, а скрам-мастеров при этом надо выбирать внутри команд. Тщательная работа с культурой сотрудников будет нужна в любом случае, впрочем об этом я уже говорил.

Распространено мнение, что Kanban является сильно упрощенным вариантом «Scrum без спринтов» для ситуации, когда команда должна просто обрабатывать поток задач. Это неверно. Kanban, в отличие от Scrum, вообще не дает какого-либо фиксированного способа организации процесса. Он запускается на основе существующего процесса и набора ролей, визуализирует поток создания ценности, а затем начинает эволюционные изменения для наращивания потока и исключения лишней работы.

Kanban может быть запущен как для одной команды, организуя его работу, с постепенным расширением области применения на смежные команды, так и для компании в целом, соорганизуя и оркеструя работы многих команд. Его естественным развитием является Lean, ориентированный на оптимизацию цепочек создания ценности. Отмечу, что речь тут идет об IT-вариантах Kanban и Lean, а не об их производственных вариантах, разработанных в Toyota. Kanban, насколько я представляю его историю, является оригинальной конструкцией, собранной на основе разных источников. Хотя он и получил свое название от использования Kanban-доски, которая является первым шагом метода и применяется для визуализации потока работ. А Lean является переосмыслением и адаптацией исходного производственного варианта для систем умственного труда, описанным Мэри и Томом Поппендик в книге «Бережливая разработка программного обеспечения» (Lean Software Development). Применяются те же механизмы оптимизации потока создания ценности, однако типы лишней работы для задач умственного труда, принципиально отличаются от типов для физического производства. Чтобы убедиться в этом достаточно сравнить лекции специалистов по производственному Lean и Lean в IT. Сейчас можно говорить о том, что объединение Lean и Kanban в IT, по моей оценке, является наиболее интенсивно развивающимся из Agile-методов, и имеет наибольший потенциал применения во всех отраслях, в связи с приходом цифрового мира, вызвавшего интенсивный переходом от физического труда к умственному.