Для вас плохая новость: 8 причин, по которым Scrum мешает вашей работе

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

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

1Совмещение ролей

Scrum подразумевает, что команда обязательно состоит из трех ролей:

• Product Owner
• Developers Team
• Scrum Master

В предложенном составе команда «плоская» — нет прямого подчинения между участниками. Scrum-команда наделена полномочиями самостоятельно принимать решения относительно разрабатываемого продукта. Роли в Scrum четко должны быть описаны: кто за какие вопросы отвечает.

Представим себе, что вы планируете внедрить Scrum в команде с классическим проектным менеджментом. В этом случе Scrum-команда начинает работать при участии менеджера проектов (Project Manager). Что происходит? PM нечем себя занять. Любые зоны ответственности, которые будут для него создаваться, нарушают баланс Scrum-команды.

Пример: отдадим PM бюджет. В результате он не регулирует ценность и содержание продукта, но в случае проблем именно он будет получать по голове. Хорошо. Добавим ему работу с ценностью продукта. Теперь можно упразднять роль Product Owner, а это уже не Scrum.

2Всегда понятные и четкие требования

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

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

3Проекты с короткой продолжительностью

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

4Команда не хочет изменений

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

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

Те, кто не принимает внутренне идеи Scrum, могут начать разрушать систему изнутри и саботировать работу по ней.

В этом случае есть несколько сценариев развития событий.

Первый — методология не приживется. Это произойдет, если команда будет против изменений или если устроит с самого начала саботирование работы по Scrum.

Второй — несколько участников не захотят работать по новой системе. В этом случае, как правило, такие участники самостоятельно покидают команду.

5Отсутствие готовности использовать все обязательные практики Scrum

У такого подхода даже есть собственное название — ScrumBut. Это такой подход, при котором вроде бы работа идет по Scrum, но как минимум:

• не проводятся ретроспективы;
• ежедневные митинги проводятся два раза в неделю;
• отказались от роли Scrum Master.

И многое другое.

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

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

6Отсутствие готовности к набору сотрудников на полную проектную занятость

Давайте подумаем над зависимостью времени продуктивной работы от количества проектов, над которыми ведется одновременная работа.

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

Конечно же в этом правиле есть исключения. Самое явное из них — Scrum Master — он может работать сразу с несколькими командами, но остальные участники команды должны быть максимально вовлечены только в один проект.

7Отсутствие поддержки от руководства

Если вы хотите, чтобы сотрудники приняли новый подход к работе, то обязательно нужна поддержка со стороны руководства. Внедрение Scrum, особенно на начальных этапах, потребует некоторых вложений. Например наем коуча или профессионального Scrum Master, обучение Product Owner, проведение обучения по Scrum для сотрудников и т.п. Руководство должно быть готово поддержать в финансовом плане внедрение методологии.

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

8Отсутствие всех необходимых компетенций в команде

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

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

Вместо заключения

Это неполный список критериев, по которым можно проверить, взлетит или не взлетит Scrum при внедрении. Но эти пункты, на мой взгляд, самые основные.

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

Это текст из личного блога, опубликованный с разрешения автора.