Некоторое время назад вышло расширенное руководство по Скрам

Некоторое время назад вышло расширенное руководство по Скрам. Авторы - сплошь люди с регалиями, небожители: Джон Коулман, Ральф Джохэм, Джефф Сазерленд.

50 страниц забористого текста мелким шрифтом предназначены для "поддержки практикующих специалистов во всех аспектах выпуска продукта самоорганизованной командой" (заявка на вечность однако).

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

Я попробовал внимательно вчитаться и приложить к себе (все-таки я и есть специалист поддержки команд во всех аспектах) советы и рекомендации профессионалов.

Но меня ждало разочарование.

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

Во-вторых, не смотря на всю прозрачность и эмпиризм скрама, как метода, за 40 лет не появилось никаких цифр, подтверждающих его эффективность. Да что там цифр, неужели за столько лет нельзя было предложить методологию оценки влияния скрам на эффективность команд и организаций. Сколько скрамов и методологов городят абсолютно безумные "аджайл-радары" и пытаются доказать ценность бизнесу. Наверняка такой запрос присутствует, но отцы-основатели, судя по всему, даже не лежат в эту сторону. Хочется даже уточнить: а не инфоцыгане ли вы часом, товарищи основатели? А вдруг начнешь вести статистику и она против тебя же и обернется?

Ну и в-третьих, в порыве графомании коллеги вывернули логику существования скрам-команд в организациях.

По мнению авторов, организация, внутри которой создается скрам-команда, должна полностью адаптироваться под нее по ценностям, ролевой модели и рабочему ритму. Да еще и загружать так, чтобы всегда оставалось примерно 15% свободных ресурсов для доведения инкремента до блеска. В кратце предлагается строить организации тепличного типа. Хочется спросить: коллеги, вы наркоманы штоле?

Я понимаю, что за 40 лет консалтинга легко утратить связь и с реальностью и первоначальным смыслом, но раз никто из товарищей по цеху ни чего не говорит, сделаю это я.

Обратимся к статье, вышедшей в Гарвард бизнес ревью в 1986 году. Здесь скрам упоминается впервые и предлагается в качестве ответа на вызов, стоящий перед бизнесом того времени: как организовать работу, чтобы ускорить выпуск продуктов до темпов, приемлемых рынками. Да и продукты надо было улучшать не по маркетинговым , а по объективным причинам. Слишком тяжелые, большие, медленные, ограниченные они были.

Ускориться надо было до способности выпускать серийные обновления продуктов каждые 3 месяца. В качестве примеров взяты кейсы компаний Ксерокс, Никон, Сони (да-да, при чтении статьи возможны острые приступы ностальгии). Меж тем проектный подход к разработке (в простонародье вотерфолл) просто физически не мог предложить таких скоростей.

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

Читателя довольно аргументированно подводят к мысли, о том, что НИОКР-подразделения должны стать неотъемлемой частью организаций, которые хотят сохранить или завоевать лидерство в новом ускоренном мире.

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