Скрам — самый популярный Agile-фреймворк. Точка. Согласно отчету VersionOne 11th State of Agile, Скрам используют 58% респондентов (или 68%, если суммировать Скрам и гибрид «Скрам/XP»). Среди масштабируемых фреймворков Скрам, безусловно, занимает лидирующее положение: на долю Scrum-of-Scrums приходится 27% (на 1% меньше, чем на Scaled Agile Framework), а на долю Scrum-of-Scrums, LeSS и Nexus вместе приходится 31%. Я полагаю, что есть две основные причины такой популярности. Во-первых, Скрам прост для понимания, и для его применения имеется подробное, чёткое руководство — «Руководство по Скраму» (Scrum Guide). Во-вторых, он помогает командам эффективно создавать сложные продукты высокой ценности в условиях неопределённости.



Может показаться, что уже в первом абзаце я делаю вывод, который противоречит утверждению, вынесенному в заголовок этой статьи. Это не совсем так. Скрам действительно работает, но только если он был успешно применён. Я не сомневаюсь в том, что Скрам — чрезвычайно мощный инструмент, эффективность которого обусловлена тесной взаимосвязью ролей, артефактов и практик Scrum. Его целостный характер особо подчёркивается и в «Руководстве по Скраму»: «Каждый из элементов фреймворка соответствует определённой цели и является обязательным для успешного использования Скрама». Это значит, что единственный способ реализовать все преимущества Scrum заключается в строгом следовании указаниям, содержащимся в Руководстве по Скраму. Но это не означает, что невозможно получить хотя бы некоторые преимущества Scrum, используя лишь части Скрама (такой подход принято называть «ScrumBut» или «СкрамНо»). При этом, во-первых, не нужно говорить, что вы используете Скрам, и, во-вторых, результаты применения такого подхода в высшей степени непредсказуемы.

Почему может возникнуть необходимость применения ScrumBut? Если исключить ситуации, когда организация ничего не знает о Скраме, то чаще всего в качестве причины указывают то, что «этот подход противоречит нашей организационной культуре». Среди основных трудностей на пути внедрения Agile-подходов большинство респондентов уже на протяжении 6 лет называют «несоответствие философии или культуры компании базовым ценностям Agile», и их доля таких ответов растёт (в прошлом году было 63%). Поэтому в процессе внедрения Agile (и Скрама) неизбежно возникает вопрос: «Как мы можем изменить организационную культуру для того, чтобы она соответствовала (или, по крайней мере, не противоречила) ценностям и принципам Agile?». Один из возможных ответов на этот вопрос известен как 5-й закон Лармана об организационном поведении (Laws of Organizational Behavior): «Культура следует структуре». Если вы действительно хотите изменить корпоративную культуру, то необходимо начать с изменения структуры. Иного пути нет. Заставьте людей работать по-другому, тогда их образ мышления изменится, и новые методы работы будут соответствовать их восприятию собственных действий. Таким и должен быть результат полноценного внедрения Скрама — создание структуры, которая обеспечивает необходимый уровень гибкости организации.

Я полагаю, Скрам работает именно так — не только изменяя способ выполнения работы, но и меняя тип мышления и убеждения сотрудников. Но люди всегда болезненно переживают изменение среды и появление новых правил, и не менее болезненно - изменение привычного образа мышления. При выборе из двух болезненных путей люди обычно выбирают менее болезненный. Или, по крайней мере, тот, который они воспринимают как менее болезненный.

Это подводит нас к пониманию главной причины неудачного внедрения Скрама: это требует слишком больших изменений (и приносит слишком много боли). Если корпоративная культура в организации в достаточной степени соответствует принципам Agile, внедрение Скрама происходит словно по волшебству: создаётся необходимое напряжение, которое способствует изменению культуры и обеспечивает успешное внедрение Скрама и Agile-трансформацию организации. Но в тех случаях, когда организационная культура далека от принципов Agile, попытка внедрения Скрама приводит к печальным результатам. В таком случае это не просто противостояние структуры и культуры, но структура, которой противостоят культура в сочетании со стремлением избежать болезненных преобразований. И мы все прекрасно знаем, сколько энергии люди могут направить на то, чтобы избежать боли. Получается, что внедрение Скрама обречено на провал, и, по большому счёту, есть только два пути последующего развития событий. Первый — вернуться назад к тому, что было, и заявить: «Скрам (и Agile) не подходят для нашей компании». Второй — изменить фреймворк Скрам так, чтобы он не создавал слишком большого напряжения (и боли). Второй путь ведёт к различным вариантам ScrumBut и карго-культов. В лучшем случае это завершается разочарованием, раздражением и снижением продуктивности (а в худшем может привести к полному разладу работы в организации).

Скрам не работает, когда он насильно насаждается в организации, культура которой плохо совместима с принципами гибкого управления. Означает ли это, что Скрам плох сам по себе? Нет. Это означает лишь то, что буквальное следование Руководству по Скраму подходит не для всех организаций, и Скрам-мастер должен тщательно продумать правильный подход к внедрению Скрама. Иногда это значит, что вместо попыток сделать «все как надо с первого раза» мы последовательно приближаем структуру и правила работы организации к тем, которые предполагаются в Скраме.