Что не так со Скрамом?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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