Вчера встречался с другом, который работает девелопером в одной известной компании. Друг в разговоре о проектах очень жаловался на то что их заставляют работать по скраму, хотя ни клиенту, ни команде это абсолютно не нужно. Мол, на каждом демо клиент спрашивает финальный срок готовности проекта, в ответ на что скрам-мастер бубнит про велосити (производительность) к неудовольству клиента. Никаких новых фич не прилетает, скоуп (объем работ) понятен. Самое смешное - друг делает глубокую оптимизацию скорости работы бэкенда, а его заставляют это показывать на демо и очень огорчаются, когда он показывает логи из браузера - это выглядит совсем не красочно.

А уже сегодня я вижу партнерский материал от этой компании на одном известном портале, рассказывающий о том как прекрасен Agile и как надо превратить всех классических проектных менеджеров в agile-координаторов.

Волшебных таблеток не бывает. Нет единственно верной и правильной методологии, которую можно везде применять и получать хороший результат. Если для внедрения методологии нужно ломать команду, нужно ломать психологию клиента и его бизнес модель, то встает вопрос - стоит ли игра свеч?

Я лично не против гибких методологий там где они нужны - в динамичных проектах, с большой частью неопределенности по бизнес-модели и по архитектуре конечного продукта, с почасовой оплатой, с высоким содержанием RnD составляющей в работе. Идеально для стартапа.
Но я понимаю почему гибкие методологии очень приятны для внедрения даже там, где они не нужны: потому что они размазывают ответственность. Иногда нужно просто взять отвественность и закоммититься на результат к нужному сроку. Иногда команда должна сказать "сделаем", расшибиться в лепешку и сделать в срок. Внутри можно использовать ту же Канбан доску или любые удобные артефакты. Но главное помнить что это клиент платит за решение его вопросов, а не за создание ему нового геммороя путем плясок с бубном вокруг того или иного процесса.