Обеспечивает понимание Scrum на уровне команды, смежников, организации, отвечает за Scrum процессы, атмосферу в команде, устранение препятствий - того, что мешает команде быть self-organizing командой профессионалов, оказывает поддержку Product Owner. Выступает в роли тренера, фасилитатора, коуча.

В Scrum Guide есть

который с шариками

это так называемый тип, который нужен чтобы вся эта бадяга завелась, так как контролить выполнение задач становится просто не реально)

но чаще получается что то вроде этого по итогу =) как бы все все красиво не расписывали)

а треккер? достаточно приучить всех участников подробно писать все детали по задачам в багтреккер, вплоть до мыслей, соображений и предположений, включая все итоги фейлов ))

дело в том, что когда проект разрастается до большого количества команды, нужен уже отдельный человек следящий за всем, так как тим лидов становится тоже больше одного, а рп уже не разрулит это)))

когда много всех - все равно треккер + руководитель стрима или менеджер потока или он же администратор проекта или же тимлид - вот такие должности есть еще ))

по мне это все те же яйца только в профиль)

а как же кодекс этики pmi или мне не стоит о нем вспоминать? )

Коллеги, вот и очередная иллюстрация, что роль скрам мастера совершенно размыта, польза непонятна. Со ссылками на скрам гайд, скрамбок, и пр.

Отличия всё-таки есть. В случае waterfall менеджер проекта несет ответственность за успех. Он даёт команде ОС по их производительности, кого-то может заменить, общается с заказчиком, рулит scope, согласовывает CR. Успех проекта определяется достижением целей проекта с учетом ограничений (где существенное ограничение scope). Нет требований по устойчивости команды и ее загрузке.

Кто со всем этим контентом и как должен работать?

В scrum результат продукт и Команда. Успех в предоставлении бизнес-ценности заказчику. Существенное ограничение сроки. Рулит scope Product Owner, он составляет роадмап проекта, но devteam решает сама, КАК она реализует эту бизнес-ценность. Ответственность за успех на всей scrum team. Scrum master не указывает им, как взаимодействовать. Он фасилитирует процессы, помня, что за velocity отвечает Devteam. Загрузка должна быть full time. И да, Devteam может попросить SM на выход. А Product Owner может набрать себе другую команду.

Самого понятия CR в Scrum нет. На может быть. Тут же каждая Цель спринта согласовывается с общим vision продукта. Приоритеты user story легко меняются РО от спринта к спринту. Но цель спринта неизменна.

Договор с открытым scope - для agile по T&M, с чётким scope - для waterfall с fixed price

Оля, ну это конечно экстремальный подход. На самом деле фикспрайсовый договор тоже может позволить вести разработку по скрам, если ты зафиксируешь объем бэклога в чем-нибудь (в сторипойнтах там или в человеко-часах). Это позволит тебе использовать гибкость управления приоритетами задач и даже учета CRов, если их можно так назвать. грубо говоря, первоначальный бэклог не догма, в нем может смениться большой объем задач, пока суммарно бэклог в рамках зафиксированного объема

тимлид или рп, в зависимости от того, какая оргструктура организации, проекта, если внешняя разработка то все другое

Понятия Тим Лидов в scrum нет. Есть devteam, где все равны. Если командой 9 чел невозможно реализовать продукт, создаются несколько команд, и там масштабирование...LeSS, SAFe :-) один РО=один продукт. При этом у одного РО может быть несколько продуктов. Один продукт не может иметь нескольких РО.