Можно ли менять Scrum, Или как адаптировать Скрам, не искажая его суть

Вольный перевод статьи Should We Change Scrum, опубликованной на официальном сайте Age of Product.

Можно ли, да и нужно ли менять Scrum, или это «преступление» — подстраиватьмонолитную структуру под нужды наших команд и бизнеса?

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

От обеспечения культурной совместимости до решения проблем технического долга и появления новых технологий — в этой статье обсудим, когда дополнения к Scrum не просто допустимы, а необходимы современным командам.

9 причин, чтобы изменить Scrum

Итак, какие же причины могут заставить вас задуматься об изменениях в Scrum? 

1. Сложность бизнеса: Сложность современного бизнеса часто выходит за рамки стандартного Scrum. Компании часто сталкиваются с взаимозависимостью между отделами и другими подразделениями, сторонними поставщиками или регулирующими органами. Адаптация Scrum с учетом этих элементов позволяет применять более целостный подход к устойчивому решению проблем клиентов.

2. Соответствие требованиям и регулирование: В отраслях с высоким уровнем регулирования необходимы дополнительные системы сдержек и противовесов. В этом случае Scrum может быть дополнен, например, специализированными ролями разработчиков, ответственных за обеспечение выполнения нормативных требований.

3. Интеграция с другими методологиями: Многие организации используют несколько agile-фреймворков или методологий. Модификация Scrum для лучшей интеграции, например, с Kanban-методом в проектах по техническому обслуживанию или Design Thinking на ранних стадиях разработки продукта, может создать более сплоченный и эффективный поток процессов.

4. Инновации: Scrum предназначен для постепенного совершенствования, но не всегда ориентирован на использование прорывных инноваций. Дополнение Scrum элементами, способствующими инновациям, например, инновационные спринты или хакатоны, позволят командам добиваться новых впечатляющих результатов!

5. Ограниченность ресурсов: Небольшим организациям или командам с ограниченными ресурсами может быть сложно следовать Scrum по правилам. Упрощение или изменение элементов Scrum может помочь организациям внедрить agile-практики без перегрузок.

6. Исследование продукта: Scrum часто критикуют за отсутствие четкого руководства по исследованию продукта. Дополнение фазой Исследования или поддержка Владельца продукта с целью направить фокус и усилия команды в нужную сторону поможет команде не просто правильно создавать продукт, а создавать правильный продукт. 

7. Ориентация на пользовательский опыт: Традиционный Scrum не делает явного акцента на пользовательском опыте (UХ). Но по мере того как UХ приобретает все большее значение в разработке программного обеспечения, растет потребность включить его в рамки Scrum, что означает интеграцию пользовательского тестирования в поток спринта.

8. Решения, основанные на данных: Scrum делает акцент на обратной связи от Стейкхолдеров, но не всегда предписывает принимать решения на основе данных. Интеграция аналитики данных в Scrum может помочь командам быть более объективными и точными как в планировании, так и в исполнении.

9. Особенности удаленной работы: Недавняя волна перехода на удаленную работу принесла целую серию вызовов. Крайне необходима адаптация Scrum для изменившейся динамики удаленной команды, например асинхронное общение или инструменты для удаленной совместной работы.

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

10 условий, когда изменения в Scrum возможны

1. Холистический взгляд: Никакие изменения не должны проводиться изолированно. Мы должны учитывать, как изменения в одной области могут повлиять на другие. Целостный взгляд гарантирует, что изменения в Scrum будут согласованными и синергетическими, а не разрушительными или конфликтными.
2. Полное понимание принципов Scrum: Прежде чем вносить какие-либо изменения в Scrum, необходимо досконально понять его основные принципы и практики. Такой подход гарантирует, что любые корректировки не подорвут фундаментальные постулаты Scrum.
3. Организационное соответствие: Изменения должны быть выгодны не только Scrum-команде, но и соответствовать общей стратегии организации. Несоответствие между практиками Scrum-команд и целями бизнеса может привести к трениям и помешать созданию ценности для клиентов.
4. Ориентированность на клиента: изменения должны быть направлены на достижение конечной цели — предоставление большей ценности для клиента. Если изменение не улучшает продукт или не делает процесс более ориентированным на клиента, его следует отменить.
5. Соблюдение этических и правовых норм: Изменения не должны нарушать правовые или этические нормы, включая трудовое законодательство и принципы корпоративного управления.
6. Четкие цели: Любое изменение должно иметь четкую, хорошо сформулированную цель — решить конкретную проблему или улучшить какой-либо аспект рабочего процесса. Эта цель должна быть измеримой и согласованной с общими целями проекта или организации.
7. Мнение команды: Scrum делает акцент на коллективном принятии решений. Команда должна обсуждать и согласовывать любые изменения в фреймворке.
8. Итеративное экспериментирование: Scrum-команда или команды должны тестировать любые значительные изменения в меньшем объеме перед их внедрением, чтобы оценить их эффективность. Экспериментальный подход позволяет вносить изменения и быстро отменять их, если изменения окажутся неэффективными или вредными.
9. Обоснование, подкрепленное данными: Scrum-команды должны использовать эмпирические данные для обоснования изменений. Например, можно использовать опросы удовлетворенности заинтересованных сторон после выпуска продукта, чтобы обосновать изменения в практике взаимодействия с заинтересованными сторонами и убедиться, что разработанный продукт соответствует ожиданиям заинтересованных сторон и целям организации.
10. Обзор и обратная связь: После внедрения изменений команда должна регулярно пересматривать ситуацию, чтобы оценить ее влияние. Обзор должен включать обратную связь от всех членов команды и заинтересованных сторон, чтобы оценивать эффективность. Следовательно, команда должна отменять все неэффективные изменения.

Давайте изменим Скрам!

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

1. Поддержка руководства: Одобрение руководства имеет решающее значение для принятия и эффективного внедрения любых изменений. Возможно, вам придется адаптировать практику Scrum, чтобы удовлетворить определенные ожидания руководства или получить необходимые ресурсы, но это ни в коем случае не должно идти вразрез с принципами Agile. Кстати, демонстрация окупаемости изменений может сыграть важную роль в получении поддержки от руководства. (Пример: вовлечение руководства в процесс релиза продукта).
2. Культурная совместимость: Организации с уникальной культурой могут не соответствовать принципам Scrum. Подстройка структуры под культурные нормы организации — это не подрыв целостности Scrum, а обеспечение ее применимости и приемлемости в различных рабочих средах. (Пример: создание отчета по спринту (Sprint Review) вслед за Обзором спринта (Sprint Review).
3. Психологическая безопасность: Психологически безопасная среда очень важна: члены команды не должны бояться рисковать и совершать ошибки. Хотя Scrum подразумевает это, делая акцент на сотрудничестве и уважении, но сделать это явным помогут регулярные контрольные встречи или специальные командные соглашения, которые можно закрепить в качестве важнейшего аспекта гибкой рабочей среды.
4. Взаимодействие с заинтересованными сторонами: Scrum упоминает роли Владельца продукта и developers (создателей), но оставляет вовлечение заинтересованных сторон довольно туманным. Расширение Scrum за счет включения в него циклов обратной связи с клиентами или внутренних проверок заинтересованных сторон может добавить еще один уровень подтверждения и согласованности, гарантируя, что разработка продукта будет в большей степени соответствовать потребностям конечных пользователей и целям организации (Пример: Включение заинтересованных сторон в процесс управления Бэклогом продукта; например, при составлении карт пользовательских историй).
5. Проблемы масштабируемости: Сам по себе Scrum не предлагает руководства по работе с большим количеством команд. Различные фреймворки, например LeSS, предлагают свои интерпретации масштабной гибкости, которые предполагают значительные изменения в «ванильном» Скрам. Понимание того, когда и как использовать такие фреймворки, требует анализа конкретного организационного контекста. 
6. Глобальные команды: При работе по всему миру часовые пояса, язык и культурные нюансы могут создавать определенные проблемы. В этом случае полезна модификация Scrum с включением асинхронных ежедневных дейли или наличие общих часов, когда вся команда доступна. Эти изменения позволяют наладить более плавное сотрудничество и эффективную коммуникацию между распределенными членами команды.
7. Технический долг: накопление технического долга может затормозить прогресс и снизить качество. Хотя Scrum не имеет прямого отношения к этой проблеме, модификация фреймворка, предусматривающая выделение времени на устранение технического долга во время каждого спринта, может создать более здоровую и устойчивую кодовую базу. Это позволит командам поддерживать баланс между предоставлением функций и качеством кода, тем самым снижая будущие риски.
8. Новые технологии: Поскольку технологии быстро развиваются, Scrum-команды должны адаптироваться к новым инструментам и методам. Будь то интеграция аналитики данных в процесс определения приоритетов в Бэклоге продукта или внедрение инструментов тестирования на основе искусственного интеллекта, фреймворк должен быть достаточно гибким, чтобы приспособиться к технологическим достижениям, не теряя при этом своей сути.
9. Обратная связь за пределами ретроспектив: Scrum в значительной степени опирается на ретроспективы для обратной связи. Однако механизмы непрерывной обратной связи, направленные на улучшения, экспертные оценки или подтверждения от клиентов, могут дополнить ретроспективы. Дополнительные возможности обратной связи гарантируют, что улучшения будут происходить постоянно, а не ограничиваться рамками спринта, стимулируя рост и адаптацию в режиме реального времени. (Пример: Проведение периодических, но регулярных ретроспектив с заинтересованными сторонами и командой).
10. Диверсификация набора навыков: Для команд, которым еще предстоит стать кросс-функциональными, рассмотрите возможность адаптации фреймворка Scrum с учетом кривых обучения, повышения квалификации, привлечения экспертов, а также преодоления или компенсации задолженности по организационной структуре. Такой проактивный подход гарантирует, что со временем команда станет действительно самостоятельной. (Пример. Преодоление разделения пользовательских исследований или обеспечения качества в Scrum-командах).

Каждый из описанных аспектов можно более детально исследовать и адаптировать под свои нужды, а тщательное согласование с основными идеями Scrum позволит добиться более полного и практичного использования концепции.

Когда не нужно менять Scrum

Как я уже упоминал выше, изменения в Scrum должны вноситься обдуманно и не идти наперекор главным принципам фреймворка, однако, существуют и антипаттерны изменений. И вот 4 основные причины, когда не стоит вмешиваться в процесс Scrum:

1. Желание быстрых побед: Скрам — это не волшебная пилюля, а основа, которая содействует определенному процессу и культуре, поэтому внедрение Scrum требует периода адаптации и обучения. Организации или команды, которым не терпится получить немедленные результаты, могут изменить структуру, чтобы ускорить процесс. Такое нетерпение может привести к срезанию углов, что часто подрывает принципы Scrum и скорее всего, приведет к проблемам в будущем или непредсказуемой производительности.
2. Фундаментальное непонимание: Часто это происходит из-за того, что Scrum воспринимают как инструмент управления проектами, а не систему разработки продуктов. Внесение изменений без понимания основ могут размыть суть Scrum и привести к мешанине из практик, противоречащих основным постулатам — гибкости, прозрачности и сотрудничеству.
3. Изменения, обусловленные предпочтениями лидеров команды: В некоторых командах формальные или неформальные лидеры могут настаивать на изменениях, которые отвечают именно их предпочтениям или стилю работы, а не учитывают интересы команды или проекта. Такого рода субъективные изменения могут привести к неравномерному распределению полномочий или ответственности, что подрывает основы сотрудничества, необходимые для Scrum.
4. Слепое следование трендам: Мир Agile не застрахован от трендов и модных веяний на один сезон. Будь то новые роли, инструменты или практики, всегда есть что-то, что захватывает воображение индустрии. Интеграция этих тенденций без критической оценки может привести к запутанному гибриду методов, лишенному согласованности. Это может превратить Scrum в неузнаваемое лоскутное одеяло, которое не сможет улучшить создание ценности и, скорее всего, создаст новые проблемы.

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

Scrum служит команде, продукту и организации, а не наоборот

Давайте не будем идеализировать Scrum как некий неприкасаемый монолит; это средство достижения, а не религия. Ведь в конечном счете нам платят не за то, чтобы мы занимались Scrum, а чтобы мы создавали ценность и решали сложные адаптивные проблемы. В постоянно меняющемся мире наши подходы к решению проблем и доставке ценности тоже должны меняться. 

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

А как думаете вы — можно ли подстраивать Scrum под продукт и структуру бизнеса или важно строго соблюдать все предписания фреймворка? Пишите об этом в комментариях — будем рады обсудить разные мнения!