Какой был опыт использования Scrum в Amazon

В Amazon каждая команда решает, будет ли она использовать какую-либо методологию или нет. Наша команда и смежные команды использовали Scrum, но не в чистом виде.
В Amazon, как и в других FAANG компаниях, ключевыми процессами являются: планирование в начале года и performance review в конце по результатам. Execution можно организовать как угодно.
Scrum, в чистом виде, плохо подходит под performance review программистов. Если программисты будут просто брать высокоприоритетные задачи из общего пула, которые относятся к разным проектам и целям, то очень сложно будет описать цельную историю достижений. Поэтому в FAANG компаниях программисты работают над конкретным проектом. Они или делают его от начала до конца (анализ, дизайн, реализация, тестирование, мониторинг и т.д.) или если это большой проект, то либо драйвят весь проект, но конкретные куски могут делать другие программисты, или делают подпроект в рамках большого проекта. В таком случае очень легко написать нарратив достижения.
Кроме того, у команды нет внешнего или даже явного внутреннего заказчика. Обычно, стейкхолдерами могут быть другие команды, которые зависят от вас, или этот проект родился внутри самой команды или пришел от высшего менеджмента. Конкретными стейкхолдерами могут выступать TPM'ы вашей или других команд, менеджемент, разрабы из других команд и т.д. Поэтому демо раз в две недели для получения фидбека и перестройки требований не происходит. Но демо у нас были раз в две недели или раз в месяц. Мы приглашали TPMов, менеджеров или разрабов из других команд. Это помогало для knowledge sharing, повышения visibility вышей работы и получения фидбека.
Различные церемонии в рамках скрама также играли роль knowledge sharing, получение фибдека, обсуждения потенциальных зависимостей между проектами и рисков.
Еще одна плюшка от скрама - это создание чувства упорядочения. Я это почувствовал только в ретроспективе, когда перешел в Facebook. В Facebook совершенно другая культура работы, не похожая на остальные компании. Сначала может быть сложно понять, как вообще организовать свои задачи — полный хаос и необходимость перестроить все привычные подходы к работе.

Как конкретно был организован процесс в нашей команде в Amazon?

Церемонии:
1) Backlog Grooming. Делали оценку сложности задач и их приоритетов. Обычно, вначале создатель таски, описывал о чем задача и зачем нужна, далее делалась оценка сложности. При необходимости задача разбивалась на несколько, если сложность не помещалась в один спринт.
2) Sprint Planning. Оценивалась капасити команды в зависимости от числа разрабов, которые будут работать во время спринта. В рамках оценки капасити учитывалось, что один разраб будет oncall, также закладывалось часть капасити на технический долг и улучшения operational excellence. Обычно, это было 20%. Еще 20% на oncall. Далее формировался спринт из высокоприоритетных задач. Каждый разработчик, по сути, добавлял следующие задачи, над которыми он планирует работать в рамках своего проекта. С учетом oncall и работы над техническими задачами.
3) Stand Ups. Тут все как обычно, что было сделано, что планируется сделать, какие риски и блокеры. Если возникали длинные дискуссии, то выписывали их отдельно и обсуждения шли только между заинтерисованными участниками.
4) Demo. Кратко презентовали свои достижения в рамках спринта. Приглашали менеджеров, разрабов или лидов из других команд, TPMов.
5) Retro. Кратко, обсуждали плюсы и минусы, составляли action items по улучшению. По факту, просто сеанс психотерапии.
Scrum Master у нас менялся раз в 3-6 месяцев. Это, просто, был один из разрабов команды.
Раз в месяц у нас был roadmap review с менеджером. Про roadmap напишу отдельным постом.