Почему Scrum вам не поможет
Вы видите как конкуренты и партнеры внедряют у себя скрам и показывают результаты выше чем у вас. Конечно же вы тоже решаетесь внедрить его у себя. Для вас есть плохая новость – при неправильном внедрении он принесет больше вреда, чем пользы.
Предлагаю ознакомиться с перечнем ситуаций в которых скрам помешает вашей работе.
1. Совмещение ролей
Скрам подразумевает что команда обязательно состоит из трех ролей: Владелец Продукта (Product Owner), Команда Разработки (Developers Team) и Скрам-Мастер (Scrum Master). В предложенном составе команда является “плоской” – нет прямого подчинения между участниками. Скрам-Команда наделена полномочиями самостоятельно принимать решения относительно разрабатываемого продукта. Роли в Скраме четко описывают кто отвечает за какие вопросы, и это тоже должно соблюдаться.
Представим себе, что вы планируете внедрить Скрам в команде с классическим проектным менеджментом. В этом случе Скрам-Команда начинает работать при участии Менеджера Проектов (Project Manager). Что происходит? Менеджеру Проектов (ПМ) нечем себя занять. Любые зоны ответственности которые будут для него создаваться нарушают баланс Скрам-Команды. Пример: Отдадим ПМ бюджет. В результате ПМ не регулирует ценность и содержание продукта, но в случае проблем именно он будет получать по голове. Хорошо добавим ему работу с ценностью продукта. Теперь можно упразднять роль Владельца Продукта, а это уже не Скрам.
2. Наличие всегда понятных и четких требованиях
Скрам создавался для разработки продуктов в условиях высокой неопределенности. Он хорошо подходит когда нужны частые релизы и быстрая обратная связь от рынка. В ситуации, когда есть детально прописанные требования, не оставляющие простора для творчества, или если обратная связь от заказчика/пользователя не важна, Скрам только тратит время команды на вещи не имеющие большой ценности для разработки продукта. Если все и так понятно, то зачем усложнять?
3. Проекты с короткой продолжительностью
В основе Скарма лежит эмпирический подход, смысл которого в том, что происходит запрос к существующему опыту команды для прогнозирования будущих успехов. Если средний проект, продолжается меньше 3 месяцев, то ваша команда просто не успеет накопить достаточно опыта, которые потом можно применять для улучшения рабочих процессов.
4. Команда не хочет изменений
Одно из ключевых требований для успешной работы Скрама – команда, которая готова работать по этой методологии и готова к подобным изменениям. Директивное внедрение Скрама – плохая идея. Внедрение Скрама требует донесения до сотрудников ценности этой затеи – “продать” им идею преимущества перехода на Скрам. Но и в этом случае нельзя гарантировать, что для команды будут близки идеи Скрама. Те кто не принимает внутренне идеи Скрама могут начать разрушать изнутри систему и саботировать работу по ней.
В этом случае есть несколько сценариев развития событий. Первый – Скрам не приживется. Это произойдет если команда будет против изменений или если устроит с самого начала саботирование работы по этой методологии.
Второй – несколько участников не захотят работать по новой системе. В этом случае, как правило, такие участники самостоятельно покидают команду.
5. Отсутствие готовности использовать все обязательные практики Скрама
У такого подхода даже есть собственное название – ScrumBut. Это такой подход при котором вроде бы работа идет по Скрам, но:
- не проводятся ретроспективы;
- ежедневные митинги проводятся 2 раза в неделю;
- отказались от роли Скрам-мастера
- и многое другое.
В самом фреймворке Скрам есть простой и понятный ответ на все подобные ситуации. Вы можете добавлять в Скрам дополнительные практики из других фреймворков, но вы не можете отказываться от обязательных атрибутов Скрама, так как это уже не будет Скрамом.
В Скрам – роли, события и артефакты тесно связаны между собой и направлены на повышение продуктивности поставки клиентам продукта максимальной ценности. Отказ от какой-либо части приводит к отдалению от этой цели.
6. Отсутствие готовности к набору сотрудников на полную проектную занятость
Давайте посмотрим на диаграмму зависимости времени продуктивной работы от количества проектов над которыми ведется одновременная работа.
Эта диаграмма – лучший аргумент в пользу вовлечения сотрудников в работу над одним проектом в один момент времени. Если она не убеждает вас, то вычтите из времени оставшегося на один проект при работе с несколькими другими то время, которое уйдет на обязательные мероприятия скрама (ежедневные митинги, ретроспективы, планирование, обзоры спринта). Вы увидите, что у участника команды остается слишком мало времени на работу по задачам проекта.
Конечно же в этом правиле есть исключения. Самое явное из них – Скрам-Мастер – он может работать сразу с несколькими командами, но остальные участники команды должны быть максимально вовлечены только в один проект.
7. Отсутствие поддержки от руководства
Если вы хотите чтобы сотрудниками был принят новый подход к работе, то обязательно нужно поддержка со стороны руководства. Внедрение Скрама, особенно на начальных этапах потребует некоторых вложений. Например найм коуча или профессионального Скрам-Мастера, обучение Владельца Продукта, проведение обучения по Скраму для сотрудников и т.п. Руководство должно быть готово поддержать в финансовом плане внедрение Скрама.
Но это не главное. Важнее, чтобы руководство понимало ценность Скрама и разделяло его, а также было готово к изменению культуры компании. “Продажа идеи” потребуется и здесь.
8. Отсутствие всех необходимых компетенций в команде
Если проекту над которым вы работаете необходим, скажем дизайнер, а у вас в компании работают только программисты, то на время проекта в команде должен появиться на полную занятость такой человек. Компания должна быть готова привлечь необходимые компетенции в команду для работы с проектом по Скраму. Если такой человек будет находиться вне команды, то возможны провалы спринтов.
Вместо заключения
Это не полный список критериев по которым можно проверить взлетит или не взлетит Скрам при внедрении. Но эти пункты самые основные на мой взгляд.