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

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

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

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

Давайте рассмотрим некоторые подмены, которые могут повлиять на вашу успешную Scrum-среду.

IT Product-менеджеры или бизнес Product-менеджеры

Некоторые компании считают, что IT Product-менеджеры и бизнес Product-менеджеры – это одно и то же. Они ошибаются.

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

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

Эквивалент этой замены в мире кулинарии равнозначен замене профессионального шеф-повара поваром из фаст-фуда. Знают ли они как готовить еду? Да. Может ли повар из фаст-фуда приготовить блюдо также, как шеф-повар? Обычно, нет.

Убедитесь, что Product-менеджеры – часть команды, которая задает вектор развития продукта. В случае, когда несколько бизнес Product-менеджеров определяют вектор развития, один Product-менеджер может разбираться с технологией для удовлетворения нескольких запросов и руководства другими бизнес Product-менеджерами в определении приоритетов. Так или иначе направление развития должно все равно определяться с точки зрения бизнеса. Зачем нужен продукт, который быстро делает то, что пользователям не нужно?

Разрешение внесения изменений в спринт

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

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

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

Создание слишком больших Scrum-команд

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

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

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

Придерживайтесь основ

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

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

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

Перевод статьи подготовлен в рамках курса "Agile Project Manager". Если вам интересно узнать о курсе подробнее, приглашаем на день открытых дверей онлайн.

РЕГИСТРАЦИЯ