“Запретите мне, Я торчу на одном и том же! Запретите мне, Всё равно уже кайф прошел!”
И.Ф. Летов “Наваждение”
Трендом в проектном управлении на протяжении двух последних десятилетий стал переход на SCRUM-процессы. Года с 2020-го возросло число людей, которые стали активно критиковать т.н. “чистый” SCRUM. Сейчас, под давлением обстоятельств, некоторые компании активно отказываются от этого фреймворка, т.к. SCRUM, который совершенствовался в теории, на практике во многих компаниях превратился в своеобразный культ, не влияющий на эффективность или даже снижающий её.
В мире победившего эджайла, SCRUM, как один из наиболее популярных методологических фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков она стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах скрам-мастеров (речь не обо всех, но о об очень многих).
Что не так со SCRUM?
Для начала пройдемся по тому, что в целом не так с тем, что должно привести к максимально быстрому появлению полезных фич инкрементов бизнес-ценности, череде постоянных релизов продукта и гибкому управлению хотелками заказчика или пользователя.
1. Зависимость проекта, команды и эффективности от скиллов скрам-мастера
Большинство из нас привыкли, что успех разрабатываемого продукта зависит, в первую очередь, от квалификации программистов, иногда от профессионализма PMов, дотошности аналитиков. В классическом подходе к SCRUM есть скрам-мастер или некто, выполняющий его роль. С этой ролью возникают дополнительные риски. Они актуализируются, если скрам-мастер свято соблюдает всё прописанное в SCRUM-гайде, слепо верит в эффективность за счет чистоты ритуалов, при этом навязывает явно неподходящие проекту принципы организации работы. До 40% рабочего времени уходит на болтовню на дейликах, грумингах и ретроспективах.
Встречи почти всегда растягиваются, а команда тратит время на многократное и бесполезное обсуждение всем, кроме скрам-мастера, понятных задач. Отдельно напрягаются PO и PMы, которые стремятся, ради соблюдения методологических догм формулировать user story там, где в этом нет необходимости, бесконечно декомпозируют эпики и т.д. Любой, кто участвовал в команде с такими евангелистами понимает о чем речь. SCRUM требует высокой степени самоорганизации и дисциплины, что не всегда возможно в реальных условиях. Лучший скрам-мастер - тот, кто умеет модифицировать фреймворк как под условия проекта, так и особенности команды (я даже таких встречал… целых два раза в жизни).
2. Сложности с адаптацией
SCRUM не всегда можно адаптировать под все типы проектов. В первую очередь, речь идёт о ситуациях, где наиболее разумным будет решить всё за одну итерацию, а попытка декомпозировать не приведет к появлению бизнес-ценности.
Это, например, касается разработки и обучения нейросетей. Когда речь идёт о подготовке ML, с разработкой самой модели, сбором данных, а затем обучением. Также любые проекты, где результаты задач сложно или невозможно получить при параллельной разработке.
В первом случае имеет смысл использовать KANBAN или экстремальное программирование. Во втором — старый добрый Waterfall. Автомобиль никто не производит, создавая и поставляя заказчику или покупателю отдельные детали, важен конечный результат. Попытки выделить отдельные инкременты в подобных проектах гарантировано усложняют процесс разработки, приводя либо к огромным спринтам, либо к тому, что конечные цели итерации никогда не достигаются.
3. Не про гибкость
На практике SCRUM не приветствует изменения задач в ходе спринта. Любой скрам-мастер скажет, что это допустимо, но такие изменения потребуют дополнительных издержек в виде оценки, планирования и декомпозиции. Доходит до абсурда, когда для добавления простой и интуитивной понятной фичи, на всякий “маловероятный пожарный случай” создаются новые артефакты анализа, проводятся встречи по оценке задачи и т.д.
В итоге, изменяется планирование, переоцениваются ранее созданные задачи, что занимает в разы больше времени отдельных специалистов или всей команды. В связи с такими проблемами как PMы, так и скрам-мастера всячески избегают включения новых задач в спринт и стараются запланировать, нередко срочные и высокоприоритетные задачи, на следующий. Почти неизбежно это приводит к задержкам и снижению качества продукта. Если продолжить аналогии с производством - это та ситуация, когда добавление надписи над кнопкой требует согласования 10 человек и изменения 5 этапов процесса. Избыточность побуждает не менять планы сразу, но дожидаться очередной итерации.
4. Высокие затраты на обучение и внедрение
SCRUM может быть эффективным для некоторых проектов (несмотря на всё описанное выше и то, что я напишу дальше), но для успешного внедрения требуется длительная и дорогая подготовка и обучение команды. Особенно болезненно внедрение проходит в компаниях, которые раньше не использовали Agile-методологии, но по прихоти руководителя, наслушавшегося обещаний продавцов воздуха курсов по SCRUM, решил “увеличить эффективность”.
Более того, речь не идет об эффективности, когда при обучении навязывают “чистый SCRUM без примеси”, изменения для которого “смерти подобны”, а отход от стандартных приёмов вероятен настолько же, насколько изменения в классической китайской чайной церемонии. Итог — сытый продавец воздуха, недовольная команда, сорванные сроки, нулевой прирост эффективности.
5. Зависимость от частой обратной связи
В SCRUM нужна постоянная обратная связь. С одной стороны — это сильная сторона методологии, на практике это делает заказчиков, PO и(или) пользователей максимально безответственными к требованиям для бизнес-ценности. Они просто знают, что завтра они могут потребовать новую фичу, форму, кнопку, они этим активно пользуются.
Частая обратная связь от заказчика или владельца продукта позволяет вносить большое количество изменений в требования, но не функции в продукт, требования фиксируются, но в дальнейшем бюрократический ад методологии затягивает поставку ценности на месяцы.
Другая сторона медали — не все заказчики готовы к такому уровню взаимодействия. В Российских реалиях они часто предпочитают видеть готовый продукт целиком, а не по частям, что делает использование SCRUM вообще бессмысленным.
“Скрипач не нужен” или что не так со скрам-мастером
Отзывы коллег о скрам-мастерах, которые я получаю, у меня ассоциируются со старым добрым советским фильмом “Кин-дза-дза”, где регулярно звучала фраза о том, что “скрипач не нужен”. Редкие исключения касались очень опытных специалистов в компаниях, которые со старта начинали со SCRUM процессами, продуктовой PandaDoc и аутсорсинговом гиганте EPAM.
Там специалисты отзывались о роли скрам-мастера, как о полезной и повышающей эффективность, но даже там скрам-мастер не воспринимается как нечто священное и неприкосновенное. Однако, если мы посмотрим на средние и малые команды, то можем обнаружить, что эта роль не только бесполезна, но практически всегда вредна. Давайте разберемся, почему.
Скрам-мастер — лишний посредник
В малых и средних командах, где все участники процесса тесно связаны и регулярно взаимодействуют друг другом, скрам-мастер становится лишним. Представьте себе, что вы находитесь на кухне, где готовите ужин с друзьями. Все знают, что делать, и тут появляется человек, который начинает раздавать указания, в каком порядке нарезать овощи, когда ставить кастрюлю на плиту и сколько соли добавить. В итоге все только раздражаются, а процесс готовки становится сложным и медленным. Именно таким «кухонным начальником» становится скрам-мастер.
Деньги ради процесса
Содержание скрам-мастера требует дополнительных затрат, которые могут быть значительными для малых и средних компаний. Эти деньги можно было бы потратить на что-то более полезное, например, на покупку нового оборудования или на обучение сотрудников. Это как если бы вы наняли личного тренера для своей кошки – затраты есть, а пользы никакой.
Скрам-мастер и микроменеджмент
Скрам-мастер может легко превратиться в микроменеджера, и это вредно не только для малых и средних команд, но и для крупных компаний. Полноценный специалист вполне способен эффективно работать без постоянного контроля, “церемониальной магии грумингов и ретроспектив”.
Микроменеджмент со стороны скрам-мастера зачастую демотивирует сотрудников и снижает продуктивность, а если в команде предусмотрена роль PMа и последний склонен к “беспокоящему контролю”, то участники проекта отправляются на очередную обязательную встречу с энтузиазмом пациента, которому необходимо пройти колоноскопию. Рыбу не нужно учить плавать, она знает как это делать.
Скрам-мастер и бюрократия
Скрам-мастер почти всегда отягощает процесс разработки бюрократией сомнительной ценности. Agile выбирают там, где важна гибкость и скорость. Работа скрам-мастера часто приводит к тому, что обязательные встречи и церемонии замедляют работу, также добавляют бюрократической описательной работы.
Хорошим образным сравнением может стать попытка организации семейного пикника в корпоративном планировщике. Большое количество формальностей, теряющих смысл в живом процессе превращают разработку в достаточно рутинный процесс, в котором его участники неизбежно теряют энтузиазм.
Нежизнеспособность абстрактной оценки задач
Еще одной ахиллесовой пятой SCRUM является оценка трудозатрат. Такая оценка – одна из ключевых практик. По идее она должна помочь команде лучше планировать и управлять своим временем. На практике абстрактные единицы, во-первых, сложны для использования теми, кто привычно оценивал работу по времени, во-вторых, слабо коррелируют с другими процессами в ИТ-компаниях.
Например, заказчик аутсорсинговой компании, как правило, просит оценить сроки, аналогично в продуктовых командах важно понимать, когда новые функции станут доступны пользователям. Стори поинты могут помочь на раннем этапе сопоставить сложность задач со временем, которое уходит на их реализацию, но, как правило, это касается относительно простых задач, которые и без стори поинтов могут получить корректную оценку.
Poker SCRUM не решает проблему от слова совсем и превращает процесс оценки в гадание на кофейной гуще. Менеджмент пытается занизить сроки для скорейшей поставки ценности. Разработчики регулярно увеличивают сроки, пытаясь предугадать сколько уйдёт на тестирование. В итоге и те и другие у себя в голове привязывают стори поинты ко времени. Эффективность снижается или, как минимум, не растет, процесс усложняется, евангелисты SCRUMа аплодируют стоя.
Итак, обобщив, получаем следующие проблемы оценки (иногда неочевидные при беглом подходе к выбору методологии, но очевидные на практике):
1. Субъективность равносильна оценке удава в попугаях, когда один участник оценки представляет себе здоровенного какаду, а второй небольшого волнистого попугайчика, при этом единицы измерения попугаев также остаются абстрактной сущностью. На деле это приводит к тому, что одинаковые оценки задачи в результате могут оказаться принципиально разными. Использование “фибы” (последовательности Фибоначчи) ситуацию на практике не улучшает.
2. Проблемы с мотивацией команды
Абстрактные оценки почти всегда негативно сказываются на мотивации команды, если нет общей договорённости о том, сколько часов (дней, лет) закладывается в условный стори поинт). Создаётся ощущение неопределенности и непредсказуемости.
5. Сложности с объяснением заказчикам
Объяснение заказчикам, особенно не связанным с отраслью и незнакомым со SCRUM, что такое стори поинты и “с чем их нужно есть” крайне непросто. Абстрактные оценки, особенно в российских реалиях, всегда вызывают недоумение и недоверие. С тем же успехом можно сказать, что проект будет готов через “несколько бананов”.
Что есть полезного в SCRUM?
Несмотря на всё описанное выше, SCRUM в модифицированном виде жизнеспособен и полезен. Его главное преимущество - это комбинирование итеративного и инкрементного подходов.
1. Спринты: Постоянное улучшение
Итеративный подход в SCRUM (использование спринтов) позволяет удобно декомпозировать работу. “Разрезать торт на части, проще чем есть его целиком”. Ретроспективы, на которых анализируются спринты реально позволяют улучшать процессы и сам продукт разработки. Так можно легче адаптироваться к изменениям и избежать масштабных ошибок. При этом важно модифицировать канонические процессы таким образом, чтобы не получить все проблемы, описанные выше.
2. Инкрементальный подход: Постепенное добавление ценности
Инкрементальный подход в SCRUM предполагает, что каждая итерация завершается поставкой ценности. Во многих (но не во всех) проектах - это позволяет демонстрировать результаты и получать обратную связь от заказчиков и (или) пользователей. Проблемы возникают только тогда, когда инкремент по определению не может влезть в заранее определенный спринт, а скрам-мастер не готов или не хочет выходить за рамки процесса.
3. Адаптивность
В идеальных условиях SCRUM позволяет командам быстро адаптироваться к изменениям требований и условий, а также вносить изменения в каждый следующий спринт. Проблемой является то, что, с одной стороны, изменения возможно понадобиться внести в уже спланированный спринт, что не кошерно. Во-вторых, процесс может превратиться в бесконечный и какая-то фича будет вечно кочевать из спринта в спринт, обрастая всё новыми требованиями, при этом не попадая в релиз.
4. Прозрачность
SCRUM действительно обеспечивает высокую степень прозрачности процесса. Дейлики, спринт-обзоры и ретроспективы позволяют всем участникам проекта быть в курсе текущего состояния дел и прогресса. Как я уже писал выше, они не всегда нужны и полезны, часто команда и так всё хорошо видит.
Когда SCRUM может быть полезен?
1. Большие проекты
В больших проектах, где требуется координация множества задач и участников, SCRUM помогает структурировать работу и обеспечить регулярные поставки ценности.
2. Проекты с равномерными и (или) типовыми задачами ограниченной длительности
Если большинство задач в проекте занимают приблизительно одинаковое время, SCRUM позволяет эффективно планировать и управлять ресурсами. Это помогает избежать перегрузок и простоев, обеспечивая равномерное распределение работы (естественно речь об идеальных или почти идеальных условиях).
3. Создание ценности за равные промежутки времени
SCRUM позволяет команде регулярно доставлять ценность заказчику, что особенно важно в проектах, где требуется частая обратная связь(когда её можно получить без танцев с бубном) и возможность вносить изменения (если левел бюрократии у скрам-мастера и PM близок к 100lv и внесение изменений не требует 100500 артефактов с сопоставимым количеством согласований для каждого).
Риски отказа от SCRUM там, где процесс удалось выстроить
Когда компании решают отказаться от SCRUM после того, как команды уже адаптировались к этой методологии и выстроены процессы, они также сталкиваются с рядом проблем:
1. Потеря структурированности и ясности
SCRUM предоставляет четкую структуру и ясность в распределении ролей и обязанностей. Когда команды привыкли к этой структуре, отказ от нее может привести к хаосу и неразберихе. Оркестр лишается дирижера – музыканты могут знать свои партии, но без координации результат будет крайне проблемным.
2. Снижение мотивации и продуктивности
Команды, привыкшие к регулярным спринтам и ретроспективам, могут потерять мотивацию и продуктивность без этих элементов. Обратная связь реально помогает командам оставаться на правильном пути и постоянно улучшаться. Можно сравнить это с теми, что на оживленной трассе отключили светофоры и убрали дорожные знаки.
3. Ухудшение коммуникации
SCRUM часто способствует улучшению коммуникации внутри команды и с внешними стейкхолдерами. Это особенно критично в больших проектах, где важно, чтобы все участники были в курсе текущего состояния дел.
4. Проблемы с адаптацией к изменениям
SCRUM позволяет командам быть гибкими и быстро адаптироваться к изменениям. Отказ от этой методологии может затруднить адаптацию к новым требованиям и условиям.
Критикуешь – предлагай
Риски, описанные выше, показывают, что полный отказ от скрам-процессов не рационален и логично предложить альтернативу, которая сохраняет его преимущества и устраняет его недостатки. Условно такую методологию можно назвать PostSCRUM. Давайте рассмотрим, какими свойствами должен обладать такой фреймворк.
-
Фокус на результате, а не на процессе
Одним из недостатков SCRUM является его чрезмерный фокус на процессе, что может отвлекать команду от выполнения реальной работы. Новый фреймворк должен быть ориентирована на результат, а не на процесс, чтобы команда могла сосредоточиться на достижении целей, а не на выполнении ритуалов.
-
Минимизация бюрократии
SCRUM может добавить ненужную бюрократию в процесс разработки. PostSCRUM должен минимизировать бюрократию и формальности, чтобы команда могла работать более эффективно и быстро.
-
Поддержка долгосрочного планирования
SCRUM ориентирован на краткосрочные цели и итерации, что может затруднить долгосрочное планирование. PostSCRUM должен поддерживать как краткосрочные, так и долгосрочные цели, чтобы команда могла эффективно планировать и прогнозировать. Отчасти таким свойством обладает гибридный SCRUMBAN.
В качестве заключения
Сейчас можно констатировать, что в практике разработки SCRUM превратился в пародию на самого себя, особенно в том случае, если методологию используют в канонически чистом “халяльном” не модифицированном виде. При этом его особенности способствовали появлению огромного количества команд, фиксированных на SCRUM-процессах, продавцов воздуха принципов “правильного” подхода к проектному управлению, церемониально фиксированных скрам-мастеров. Вангую, что активное использование SCRUM в мире стало одной из причин катастрофической статистики успешности agile-проектов (исследование показало, что у agile-проектов на 268% выше процент неудач) https://johnfarrier.com/agile-failure-what-drives-268-higher-failure-rates/.
Очевидно, что при всех теоретических преимуществах, SCRUM провалился на практике и требует значительной модификации для того, чтобы стать эффективным.
Автор: Mi_sha256
