Картинка взята с данного ресурса.

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


Перемен. Мы ждём перемен.
Картинка взята с данного ресурса.

5. Вы не готовы использовать все обязательные практики Скрама

Для этого подхода даже придумали специальный термин ScrumBut. Это когда мы работаем по Скрам, но… Мы не проводим ретроспективы. Но Daily meeting у нас 2 раза в неделю. Но мы отказались от роли Скрам-мастера. И много других подобных «но».

Фреймворк Скрам даёт простой и понятный ответ на все эти ситуации. Да, вы можете добавлять дополнительные практики в Скрам-процесс вашей команды (например, практики из XP). Но нет, вы не можете отказываться от каких-либо элементов Скрама, так как это уже будет не Скрам.

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

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

Видели график зависимости времени продуктивной работы от количества проектов, над которыми вы работаете одновременно? Если нет, то смотрите.



Сама эта диаграмма является лучшим аргументом в пользу вовлечения сотрудников в работу над одним проектом в один момент времени. Но если и она вас не убеждает, вычтите из времени, оставшегося на один проект при работе с несколькими другими, время, которое уйдёт на обязательные встречи (ежедневные митинги, ретро, планирование, обзор спринта). У участника команды останется слишком мало времени на работу по задачам. Оно вам надо?

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

7. У вас нет поддержки со стороны руководства

Также как мы хотим, чтобы сотрудники приняли новый подход к работе, мы нуждаемся и в поддержке со стороны руководства. Важно понимать, что внедрение Скрама, особенно на
ранних этапах, может потребовать некоторых вложений. Например, найм Agile-коуча или профессионального Скрам-Мастера, обучение Владельца Продукта, проведение обучения по Скраму для сотрудников и многое другое. Руководитель должен быть готов поддержать новое начинание финансово.

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

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