Разница в том, что Agile — это лишь общая система ценностей, а не способ организации работы. Поэтому выражение «работать по Аджайлу» не имеет смысла (в отличие от «работать по Скраму»).

Scrum — это все же руководство к конкретным действиям (базирующимся на ценностях Agile): проведение 4-х конкретных встреч, работа с 3-мя конкретными артефактами, более-менее конкретное разделение ответственности между людьми.

Впрочем, Скрам — это фреймворк («каркас»), а отнюдь не набор директив, и Руководство по Scrum гласит: «Scrum не предоставляет людям подробных инструкций, вместо этого правила Scrum задают ориентиры для отношений и взаимодействий людей».

Не совсем. Помимо системы ценностей, зафиксированных в Agile-манифесте, слово «Agile» имеет второе значение: под этим словом часто имеют ввиду совокупность разных гибких фреймворков (например, Scrum, LeSS, SAFe) и методов (например, Kanban, хотя этот метод и не базируется на ценностях Agile). Слово «методология» тоже означает совокупность методов, но на этом сходство этих двух слов заканчивается.

Большинство практиков гибкого управления сейчас уже НЕ называют Аджайл методологией. Хотя словосочетание «методология Agile» было действительно популярно, поскольку методологиями были предшественники Agile — например, RUP и XP.

Чем Agile отличается от методологий

Нет, но есть нюанс. Scrum — это фреймворк, который помогает строить рабочие процессы. Основная область применения Скрама — это НЕ разовые проекты с фиксированным сроком и/или объемом работы, а «продукты», которые постоянно улучшаются во взаимодействии с клиентом.

Нюанс в том, что Scrum не противоречит проектам, хотя и является «продуктовым подходом». Многие проекты достаточно длительные и имеют высокую степень неопределенности, поэтому в них Scrum вполне может использоваться. Так что в 2020 году из определения Scrum убрали слово «продукты». Подробнее о проектах в продуктовой компании

А «Scrum. Революционный метод управления проектами» — это просто некорректный русский перевод названия книги Сазерленда (создателя Скрама). Кстати, саму эту книгу — которую автор назвал «Scrum. The Art of Doing Twice the Work in Half the Time» — вполне можно рекомендовать к прочтению… однако лишь после того, как вы прочитаете актуальную версию Руководства по Scrum.

Scrum Master (SM) — это роль в Scrum-команде, хотя и отнюдь не всегда это должность: бывает, что эта роль совмещается с ролью разработчика, например. В условиях отсутствия в Скраме роли менеджера (или даже тимлида), скрам-мастер отвечает за рабочий процесс и за общую эффективность команды (тогда как за конкретные бизнес-результаты отвечает владелец продукта). Для этого SM:

• обучает команду, приучает ее коллективно принимать решения и отвечать за результат;
• обеспечивает, чтобы люди конструктивно общались и не ссорились, — в том числе, за счет грамотного проведения (фасилитации) Scrum-встреч;
• способствует устранению внутренних и внешних препятствий, мешающих прогрессу Scrum-команды.

Подробнее о функциях скрам-мастера

С точки зрения Scrum, Product Owner (PO) — это роль, а точнее, «зона ответственности» в Scrum-команде. PO отвечает за то, чтобы создать классный продукт, ценный для клиентов и в конечном итоге приносящий деньги бизнесу. «Product Owner — это один человек, а не комитет».

Подробнее о функциях владельца продукта в Scrum

Если смотреть на эту роль с точки зрения современного рынка труда, то владелец продукта — это некая разновидность менеджеров продукта, которая так или иначе связана с Agile. В чистом Скраме (в т.ч. в LeSS) Product Owner имеет больше полномочий, чем Product Manager, а в SAFe — меньше (см. подробное сравнение двух ролей). Но на практике полномочия PO очень сильно варьируются, зависят от конкретного человека, продукта и организации.

Ответы на такие вопросы должны основываться как на логике, так и на эмпирических данных от организаций, уже попробовавших Agile/Scrum.

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

Впрочем, вряд ли есть организации, где условия применимости выполнены на 100%. Поэтому подумайте, насколько вам / вашей организации / руководству нужны эти выгоды и насколько ваша организация готова ради них к весьма радикальными изменениям — например, в оргструктуре и в степени вовлеченности заказчиков в разработку.

Что касается данных для того, чтобы принять решение или дать аргументы руководству, — они условно делятся на общую статистику и конкретные кейсы применения.

• Статистику о целях и выгодах внедрения гибких подходов (и многие другие данные) можно найти в исследованиях Agile в России (пример).
• Кейсы в видеоформате можно посмотреть выше. Другие кейсы в текстовом формате описаны здесь.