Тут такое дело... Можно выделить... ну, назовём их "маркеры". Точный и полный список я нигде не видел, в разных статьях проскакивает. И из личного опыта. Может кто ещё что добавит, мне было бы интересно.

1. Гибкость. (пожалуй, самый главный) Как часто в процессе разработки будут вносится изменения в требования.

Если ваш клиент с самого начала твёрдо уверен в том, что ему нужно, или вы делаете одно и то же с небольшими косметическими изменениями в 100-й раз, скрам не нужен. Берите водопад / критический путь (critical path) / канбан.

Если клиент хочет "чтобы оно вот где-то тут так, а потом - вздыыышь! и всё сиреневое! И кнопку!" - скорее всего скрам вам сильно поможет.

2. Организация. Готовы ли вы к изменениям в организации. Если нет - забудьте про скрам, не взлетит. Про "правильный" размер команды уже говорили, что 5-7. Имхо, скорее 5, чем 7. 3 - мало. И надо будет менять организацию, чтобы создать такие команды. Без тим ляйтера! (сколько у нас было воплей по этому поводу...) Если одна команда должна работать одновременно с несколькими проектами, сможете ли вы найти ПО, который сможет отвечать за все эти проекты? Два и более ПО (бывает) это труба.

3. Личные качества. Готовы разработчики брать на себя ответственность и принимать решения? Многие программисты в скраме работать не могут. Они воспринимают только приказы сверху а обсуждать решения с коллегами и потом принимать решение не в состоянии (а чо он мной командует? да кто он такой чтобы решать!). У них этакая вера во всезнающего и безупречного тимлида. "Начальстворианство" :)

Готовы будущие ПО понимать что их постановку задач могут (и будут) обсуждать, задавать вопросы вроде "а зачем это вообще" да и просто объяснять им почему такая постановка задачи неправильная.

Готовы менеджеры отказаться от красивых графиков релизов "через 6 месяцев будут реализованы следующие фичи"?

4. Размер проекта. Если время разработки проекта 1-2-3 недели - не стоит затеваться со скрамом (но тут скорее противоречие с 1-м пунктом, так быстро делается то, что в начале хорошо известно).

5. Срок жизни проекта. Если лепится страничка, которая через 6 месяцев точно будет заменена чем-то другим, то вам обычно наплевать на качество кода, распределение знаний о проекте по команде, документацию. Скрам не нужен.

6. Требования к качеству (понятный, легко изменять) кода / документации. В скраме есть Definition of Done (DoD). Можно задать требования к выполненной истории очень жёстко, прописать какую документацию надо править, какие тесты обязательно выполнять. Если вам всё это не надо - то и скрам вам может быть не нужен.

Имхо, важные - первые три пункта. Если они у вас выполняются, скрам поможет организовать разработку. От привычки обсуждать истории на рефайнменте (если ПО готов воспринимать критику, а не "я - начальник, ты - дурак") до чётко отработанного процесса деплоймента (с DevOps хорошо уживается). Программисты в команде через какое-то время действительно станут "взаимозаменяемыми" и не будет такого что спец по БД заболел/ушёл в отпуск, никто его базу не трогает, боится. Вырабатываются привычки делать ревью, проверять документацию коллеги - а понимаю ли я её, а вдруг он чего забыл.

"Щупать" удобно на каком-нибудь исследовательском проекте. Когда дают время месяцев 6, задачу в общих чертах (а напишите нам анализатор логов, а что конкретно он анализировать будет - посмотрим) и команда пробует а как оно будет - работать с микросервисами (например). Потому что нет давления "штоп к 1-му все блестело и переливалось!" и действительно часто меняется что же надо сделать.

Ну или идти в уже существующую команду, смотреть сможете ли втянутся.

В одиночку "щупать" - бессмысленно.

P.S. Сейчас перечитал, как-то сумбурно у меня ночью получилось... Ну, если б ребёнка спат не укладывал бы то вообще не написал бы.