Чтобы ответить на этот вопрос, вначале давайте ответим, почему Скрам стал таким популярным фреймворком в Software development?

Большинство людей скажут, что залог успеха в его простоте. И будут правы.

Скрам гайд помещается, примерно, на 10 страницах (привет PMBoK), а в нём самом простые церемонии и правила.

Поэтому многие компании и команды внедряют Скрам быстро и просто.

Но тут кроется большое заблуждение. 

И Скрам, на самом то деле, куда сложнее внутри (попробуйте сдать PSM I просто прочитав пару раз гайд (про PSM II и III вообще молчу)) и внедряют 99% не Скрам, а лишь его элементы. 

Многие ошибочно думают, что Скрам это гибкий фреймворк. 

"А разве не так?" - спросят многие - "Он ведь относится к Agile. А это про гибкость."

Скрам, на самом деле, это жесткий набор правил и настоятельных рекомендаций. 

Дейлики растягиваются до 30 минут - нет, это не Скрам.

Решили скипнуть ретро, так как команда вымотана в конце спринта - нет, это не Скрам.

РО решил сам погрумить задачи без команды - нет, это не Скрам.

Нет Скрам мастера - нет, это не Скрам.

Сделали шаг влево от гайда - нет, это не Скрам.

Соблюдать все обязательные пункты и следовать рекомендациям Скрам гайда 99% командам сложно (а иногда просто и невозможно), но без этого, Скрам гайд говорит: «У вас не Скрам». 

И тут есть один нюанс: у 99% команд не Скрам, но все при этом все они как-то работают. Ведут разработку. Добиваются каких-то результатов. 

Я видел команды, у которых от Скрама были только дейлики (растянутые иногда до часа) и спринты (каждый раз с разной длительностью). Но при этом, они говорили, что работали по Скраму и умудрялись деливерить приличный результат. 

Да, Скрам подойдет не всем, не каждой компании/команде. Но его в чистом виде и нет почти нигде. 

Зато его элементы есть повсюду. И по отдельности они тоже отлично работают и помогают достигать целей.

Жалко, что такое подход Скрам запрещает называть Скрамом.

Дак в чем же сложность?

Один из главных факторов, создающих сложности для многих команд, - это его философия.

1.Сложность для новичков и неподготовленных команд:

Философия Scrum предполагает высокую степень самоорганизации, коллаборации и обучения на практике. Для команд, которые только начинают свой путь с Agile-подходами, внедрение Scrum может быть сложным. Новым участникам может быть трудно понять ценности Agile и адаптировать свои повседневные практики под принципы Scrum.

2. Ограниченная применимость в некоторых ситуациях:

Хотя Scrum может быть эффективным для большинства проектов, существуют определенные сценарии, в которых он может быть ограничен или неэффективен. Например, проекты с высокой степенью неопределенности или постоянно меняющимися требованиями могут столкнуться с трудностями в применении строгих рамок Sm.

3. Проблемы масштабирования на большие проекты и в организации с несколькими командами:

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

4. Ограничения гибкости, особенно в отношении быстрой реакции на изменения:

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

5. Проблемы с коммуникацией и координацией внутри команды и между командами:

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

6. Отсутствие формальной документации может привести к проблемам в передаче знаний и управлении знаниями:

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

7. Недостаточное внимание качеству продукта из-за упора на быструю доставку работающих продуктов:

Из-за фокуса на доставку работоспособного продукта в конце каждого спринта, некоторые команды могут уделить недостаточно времени тестированию и обеспечению качества. Это может повлиять на стабильность и надежность окончательного продукта.

8. Не всегда подходит для проектов с жесткими временными рамками или высокой степенью неопределенности:

Scrum предполагает гибкость, но в проектах с строгими временными ограничениями или когда требования меняются ежедневно, использование Scrum может быть сложным или неприменимым.

9. Сложности оценки и планирования, особенно при работе с неопределенными или новыми задачами:

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

10. Трудности в изменении рабочей культуры и привычек команды для соответствия принципам Scrum:

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

В заключение, фреймворк Scrum имеет ряд недостатков, связанных с его сложной философией. Сложность для новичков, ограниченная применимость в некоторых ситуациях и трудности масштабирования являются главными проблемами, которые могут возникнуть при использовании Scrum. Несмотря на его популярность, командам следует тщательно рассмотреть свои потребности и реальные возможности перед принятием решения внедрять данный фреймворк.