Scrum вам не поможет. Разбираемся, почему

1. Вы планируете совмещать роли из классического проектного менеджмента и Скрама

Скрам-команда в обязательном порядке должна включать в себя 3 роли: Владелец Продукта, Команда Разработки и Скрам-Мастер. В рамках предложенного состава команда остается «плоской», то есть мы не имеем прямого подчинения между участниками. Такая команда наделена полномочиями самостоятельно принимать все решения относительно разрабатываемого продукта. Роли в Скраме чётко описывают, кто и за какие вопросы ответственен.

Теперь представьте, что вы планируете внедрять Скрам в команде с классическим проектным менеджментом. Тогда Скрам-команда начинает работать при участии Project Manager’a. Что происходит в таком случае? Фактически, PM просто нечем себя занять в таком проекте. Любые зоны ответственности, которые мы ему передаем, создают дисбаланс в Скрам-команде. Отдадим PM бюджет? Отлично, то есть PM не регулирует ценность и содержание продукта, но в случае проблем именно он будет получать по голове. Отдадим ему ещё и работу с ценностью продукта? Тогда можно будет упразднить Владельца Продукта. Но это будет уже не Скрам.



Как меняются роли и задачи в команде с приходом Скрам

2. Вы работаете с предельно понятными требованиями

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

Когда и так все понятно, зачем усложнять?

3. Вы работаете с проектами небольшой длительности

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

4. У команды нет желания менять подход к работе

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

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

Второй вариант: один или несколько участников не захотят работать в новой системе. Обычно такие ситуации заканчиваются тем, что «проблемный» участник покидает команду самостоятельно.

Читайте полный материал эксперта на официальном блоге компании на Habr.