Основные причины, почему Agile/Scrum/Kanban не используются или используются в измененном виде в FAANG-компаниях

1) Устройство performance review. Перфоманс оценивают по достижениям сотрудника за 6–12 месяцев. Если разраб просто берёт самые приоритетные таски из бэклога разных проектов, сложно сформулировать конкретный нарратив достижений. А вот если он ведёт один-два проекта или крупные части проекта с чёткими delivery и измеримым импактом, нарратив собрать проще: «сделал X — надои выросли на Y». Это звучит лучше, чем «закрыл 100 500 тасков».
2) Нет заказчиков, которым нужно показывать demo, получать фидбек и учитывать его дальше при разработке. Обычно в конце спринта делают демо того, что было сделано, получают обратную связь и, если это целесообразно, вносят соответствующие изменения. В FAANG-компаниях часто нет чётких заказчиков: либо их нет вовсе, либо это внутренние стейкхолдеры — другие разрабы из других команд. В Facebook, например, предпочитают уведомлять о достижениях, релизах, апдейтах и изменениях асинхронно: просто пишут пост в группе, и люди могут его прочитать, полайкать и написать комменты.
3) Внутри команды, разрабы работают над малосвязанными проектами. Т.к. разрабы ведут большие проекты, они часто не влияют друг на друга напрямую в рамках одной команды. Взаимосвязь внутри команды бывает, но редко. Чаще — депенданси на другие команды и разрабов из них, которые делают свою часть проекта, в котором вы участвуете. Поэтому делать спринты в рамках одной команды особого смысла нет. Больше смысла — спринты по каждому проекту, где участвуют люди из разных команд, а не из одной. Например, в вашей команде 3 разраба: A, B, C. Разраб A работает над проектом X, делает часть проекта X' и взаимодействуют в рамках проекта с коллегами из других команд, которые также работают над проектом X и делают части этого проекта X'', X'''. Разраб B аналогично работает над проектом Y и делает часть этого проекта Y' и взаимодействует с коллегами из других команд, которые делают части проекта Y: Y'', Y'''. Потом разраб A переключается на какой-то другой проект и взаимодействует с какими-то другими коллегами из каких-то еще команд.
4) Т.к. проекты большие и длительные, то спринт в 2 недели особого смысла не имеет. Обычно у вас есть какие-то промежуточные майлстоуны и деливери, но они чаще длиннее 2 недель. Просто держать 2-недельный ритм ради ритма смысла нет. Поэтому чаще делают weekly sync в рамках проекта (а не команды) и чекают статус всех майлстоунов: on track, at risk и т.д.

Тем не менее, в Amazon у нас был Scrum. А в Facebook я первый год его внедрял в своей команде. Но потом понял, что это не нужно.

Смотри также:
Какой был опыт использования Scrum в Amazon
Плюсы от того, что у нас был Scrum
Используют ли FAANG компании Scrum или Kanban?