Главная ложь SCRUM. Откуда берётся карго-культ

Всем привет. Меня зовут Рома, я-разработчик. За короткое время, в одной команде, на одном проекте, я поработал в трёх разных вариациях скрама. Ощущались они по-разному, и каждый новый вариант нравился мне меньше предыдущего. В этой статье я поделюсь своим опытом и выводами.

Дисклеймер

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

Я намеренно абстрагировался от проекта. Вместо этого я сосредоточусь на своих мыслях и ощущениях. Я сделал так по нескольким причинам:

• У меня недостаточно опыта, чтобы оценивать управленческие решения.

• Моя точка зрения субъективна.

• Статья имеет негативный оттенок. Я не хочу никому навредить, а также не хочу ни от кого зависеть при её написании.

• Условия на проекте и опыт читателя всё равно будут отличаться от моих.

• Забегая вперёд, скажу что источник проблем я нашёл за пределами проекта.

Рефлексирую

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

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

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

• Скрам мастера и коучи не помогают мне решать проблемы. Если попытаться добиться от них чётких шагов для решения проблемы поделившись симптомами, они начинают уходить от ответа или выдают в качестве отписки неадаптированную или вообще рандомную практику и предлагают пробовать. Мне не подходит то, что они предлагают. Общение заканчивается когда я теряюсь и не могу больше задавать вопросы, а не когда моя проблема решена.

• Я не могу воевать с группой из нескольких десятков человек, которая ещё и владеет правилами игры. Да и нужно ли? Возможность влиять на процессы формально декларируется, в реальности мне недоступна. Меня просто сминают сложность и неопределённость, помноженные на скорость изменений.

• Я потерял контроль над своим компонентом, но получил титул владельца исходного кода этого компонента. Когда титула не было, контроль был. Часть процессов была целенаправленно деконструирована, в рамках трансформации, остальное обвалилось следом.

• Я проваливаю задачу за задачей. То что нужно проекту, и то что я умею окончательно перестало пересекаться, я больше не на своё месте.

• Распад мотивации. Я больше не приношу пользу но трачу ресурсы и не могу с этим ничего сделать. Я это понимаю, люди вокруг это понимают, но ничего не меняется. Так не может вечно продолжаться.

• Положившись на веру в пользу изменений, я сам приложил руку к уничтожению того, что считал важным. И теперь сожалею об этом.

Анализирую

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

Иногда я прокручивал в голове те или иные воспоминания, между делом, когда нечем было заняться. Спустя где-то полгода после увольнения, идя по улице, я думал и пытался найти причину моего дискомфорта. Я так делал и раньше но не мог ни за что зацепиться. Но в этот раз, вместе с ощущением поддельности процессов, пустой оболочки вместо настоящего инструментария, в голове всплыла фраза: «Вы можете изменить компоненты скрама но результат такой модификации скрамом являться не будет». Так говорят, когда при внедрении скрама команда понимает что он им не до конца подходит и предлагает изменить его. Коучи, во время обучения, делали ударение на том, что скрам это фреймворк, не методология управления, не подход а именно фреймворк, в таком виде это можно прочитать в скрам-гайде. Это считается очень важной деталью и подаётся с особым акцентом. Здесь что-то не так. Где вы видели чтобы в другом настоящем программном фреймворке было так написано? И звучало бы это как-то так: «Да вы можете использовать не все модули Spring в своём приложении или изменить их, но такое приложение считаться Spring-приложением не может». Это же бред! В этом что-то есть но пока непонятно что.

Прошло ещё несколько дней, я снова вернулся рассуждению, и следом пришла мысль: «Эта фраза звучит знакомо, я её слышал раньше, про что ещё так можно сказать?». Так говорят про стандарты. Если думать о скраме, не как о фреймворке, а как о стандарте, то многое встаёт на свои места: «Вы можете изменить детали реализации своих процессов, отойдя от стандарта скрама, но тогда ваши процессы не будут считаться реализацией скрама». Теперь это имеет смысл. Процессы не становятся хуже или лучше если отойти от скрама, они просто перестают быть скрамом. Вот она, нестыковка которая мне не давала покоя. Несмотря на то что в скрам гайде написано что скрам это фреймворк, несмотря на то что коучи делали особый акцент на то что скрам это фреймворк, несмотря на то что все вокруг считают его фреймворком и используют как фреймворк, скрам не ведёт себя как фреймворк. Он ведёт себя как стандарт. Тот у кого недостаточно опыта с программными фреймворками и стандартами ни за что не ощутит разницу между этими концептами в контексте неформального взаимодействия между людьми. Я считаю именно эту ошибку в определении главной ложью скрама. Когда люди пытаются использовать стандарт как фреймворк единственное что они могут это следовать за нормами стандарта упуская из виду реализацию. Так, по моему мнению, и возникает карго-культ.

Делаю выводы

На что же может повлиять ошибка в определении скрама? Это изменение заставило меня взглянуть под новым углом на многие вещи, которые доставляли мне дискомфорт. Я совершенно по-другому построил бы своё поведение, вместо поддержки изменений и слепой веры в их пользу, я бы активно сопротивлялся. Даже если бы из этого ничего не вышло, я бы потратил меньше ресурсов, своих и чужих, впустую. Дальше я опишу отдельные детали которые встали на своё место после обнаружения источника проблем.

Когда я листал скрам-гайд, я испытывал ощущение что с ним что-то не так. Когда читаешь что-то что называется гайд, ожидаешь описание последовательности действий, и эта последовательность должна приводить к воспроизводимому положительному результату. Как гайд по рпг, где написано какие статы и скиллы нужно прокачать, а также как ими пользоваться чтобы тащить. А в скрам-гайде нет никакой последовательности действий, там только перечисление концептов скрама, их определений и взаимосвязей. Это не имело смысла, до мысли о том что скрам это не фреймворк, а стандарт. У стандартов нет гайдов, у стандартов есть спецификации. Неважно как именно ты реализуешь стандарт, важно чтобы твоя реализация удовлетворяла спецификации. Скрам-гайд вводит читателя в заблуждение ещё до того как тот его откроет. Скрам-гайд это не гайд по скраму, это не гайд к скраму, это вообще не гайд, это спецификация стандарта «SCRUM».

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

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

Структура скрам гайда выглядит иронично. Авторы рассказывают о том что скрам основан на эмпирическом подходе, о том что знания происходят из опыта, об итеративности и сборе знаний в процессе работы, как всё это важно. А потом берут и декларативно описывают концепты скрама, игнорируя путь, который привёл к формулированию этих концептов. Какие ошибки привели к появлению того или иного артефакта? Какие пробемы могут возникнуть в ходе реализации артефакта? Как их избежать? Ничего из этого в «гайде» нет. Можно понять почему так сделано, ведь проекты разные и пути будут разные, непонятно какой толк в таком «гайде». Я напираю на скрам-гайд, но и другие книжки по скраму, в которые я заглядывал, структурированы так же.

Скрам-гайд толкает читателя на неправильный путь, подменяя индукцию (выявление отдельных проблем, и построение обобщённого решения) на дедукцию (выделение отдельных шагов из обобщённого решения которое когда-то привело другую команду к успеху).

Аджайл-коучи и скрам-консультанты это не наставники, они не учат строить скрам, они продают стандартизацию под видом улучшения. Эти ребята с радостью помогут откинуть все старые процессы и заменить их суррогатами, их совершенно не волнует то как ты будешь работать в новых условиях и сможешь ли вообще, это не их проблемы а твои. Их критерий успеха — соответствие процессов стандарту скрама а не нуждам команды. У меня сложилось впечатление что аджайл-коучей используют не для помощи в переходе от старого к новому а для создания повода к такому переходу. И метод создания такого повода заключается в принуждении через уничтожение альтернатив. Когда речь идёт о коуче (тренере) ожидаешь что он научит тебя тому чего тебе не хватает для работы Приведу в пример плавание: учитель научит держаться на воде, расскажет о разных техниках, подберёт самую простую, будет страховать во время практики. Коуч же учит плавать выбрасывая из лодки. После чего он будет, сидя в лодке, предлагать тебе практики в надежде что ты с их помощью адаптируешься к новым условиям и выплывешь сам. Я не адаптировался. Мне не следовало позволять выкидывать себя из лодки.

Скрам-мастер, не совмещающий эту роль с какой-либо другой прикладной ролью, это не помощник. Скрам-мастер не помогает работать по скраму, он следит чтобы процессы, по которым работает команда, оставались скрамом. Он не расширяет возможности новыми инструментами а ограничивает их рамками стандарта. Такой человек с радостью введёт 15 минутное ежедневное дейли и будет следить чтобы лимит времени не был превышен. Будет ли это событие полезно - не его проблема. Он профасилитирует любую встречу но не поможет добиться цели этой встречи, если команда не справляется. Фасилитация будет заключаться в следовании стандартному шаблону этой встречи. Проблем добавляет название роли, если в русском языке мастер означает профессионал, знаток своего дела то в оригинале это повелитель, господин, в общем это человек навязывающий свою волю. Я долго думал каким же словом лучше заменить master. Ни английское master ни русское мастер, по моему мнению, не отражают сути. В итоге я остановился на слове арбитр. Проведу аналогию с футболом. Если тимлид, архитектор и менеджер(нацеленный на качество) это тренеры и такие люди могут научить полезным именно тебе приёмам, продумать тактику и стратегию, а главное тренер работает в интересах команды, ему важна победа, то скрам-мастер это арбитр, он следит чтобы никто не трогал мяч руками, назначает пенальти, объявляет перерыв, ему плевать победит твоя команда или нет. Если тренеру дать команду шахматистов он научит их играть в футбол, после работы с ним они станут намного сильнее чем были раньше, арбитр же заставит их играть по правилам и на этом всё. Поэтому команде которая справляется отдельный скрам-мастер не нужен, а команде которая не справляется он не поможет.

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

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

Говорят что скрам это одна из штук которые легко освоить но тяжело овладеть в совершенстве. Если же держать в голове что скрам это стандарт, то всё выглядит иначе. Профессионалом ты становишься после того как целиком зазубрил стандарт. Всё, после этого можно претендовать на позицию скрам-мастера и успешно работать. Беда в том что этих знаний недостаточно для того чтобы построить процессы. Именно эта неточность выглядит как владение скрамом не в совершенстве. Знания по решению проблем уже не входят в предметную область стандарта скрама. Это навыки тимлида/архитектора/менеджера. Теперь мне понятно откуда вокруг так много скрам-мастеров занимающихся только скрамом и почти не выходящих за его пределы.

Чтобы построить хорошие процессы не нужно строить скрам, нужно решать проблемы. И через какое-то время сверившись со скрам-гайдом обнаружить что получился скрам (или не получился, ведь цель была не в нём).