Категории зависимостей

Зависимость (анг. Dependency) — это потенциальное препятствие, которое тормозит, либо блокирует работу Scrum Команды.

Выделяют три основных категории зависимостей, с которыми сталкивается Scrum Команда. И каждая категория зависимостей отличается своей сложностью.

Внутрикомандные зависимости

Наименее сложный сценарий зависимости — это когда одна команда обладает всеми навыками, необходимыми для создания завершенного и потенциально готового к развертыванию элемента бэклога продукта (PBI). У команды нет внешних зависимостей. Тем не менее, члены команды все еще могут столкнуться либо с:

Элементами бэклога продукта (PBI), которые зависят друг от друга, и/или,
С задачами в спринте, которые зависят друг от друга.

В любом случае, самоуправляемая команда со Скрам Мастером (Scrum Master), обладающим отличными навыками фасилитации, должна быть в состоянии понять эту зависимость самостоятельно. В случае выявления таких зависимостей разработчики разъясняют Владельцу Продукта (PO) технические зависимости, и Владелец Продукта использует эту информацию для переупорядочения продуктового бэклога. Что касается зависимостей между задачами в спринте, то разработчики несут ответственность за координацию действий по этим задачам.

Что может помочь:

Переработайте и декомпозируйте элементы бэклога таким образом, чтобы они были более независимыми друг от друга. Это лучше всего сделать до планирования спринта, во время Рефайнмента (Refinement), но также можно сделать и во время планирования спринта.

При планировании спринта важно понять потенциальные риски, создаваемые зависимостями, и договориться том, как они будут решаться. Например, возможность выбора между Путем A или B для Элемента 2 не может быть реализована до тех пор, пока Элемент 1 не будет завершен. Следует внимательно следить за этими зависимостями во время спринта.

Межкомандные зависимости

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

Тут можно начать с простого - с координацией между самоуправляемыми командами.

Что может помочь:

Чтобы свести к минимуму противоречащую информацию, у вас должен быть только один Владелец Продукта.

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

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

Используя Scrum of Scrums, представители команд также могут координировать действия до и после планирования и Обзора Спринта (Sprint Review).

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

Внекомандные зависимости

Это самый сложный случай — когда Скрам Команда не может выполнить всю работу, необходимую для доставки элемента бэклога спринта. Им нужна помощь или поддержка со стороны:

Другой скрам-команды,
Другого отдела или,
Внешнего поставщика.

Практикуют ли внешние стороны, от которых зависит команда, Agile подход и практикуют ли они Скрам?

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

Если же нет, и вы пока не можете этого изменить, то Скрам Команде придется планировать свою работу в соответствии с графиками внешней стороны. Нужно убедиться, что задачи по мониторингу и работе с этими зависимостями учтены в Капасити (Capacity) команды.

Что может помочь:

Запросите подтверждения по доставке от внешних сторон. Получите информацию по объемам работ и конкретные даты.

Контролируйте ситуацию. Приглашайте внешних представителей на ежедневные встречи команды – Daily Scrum. Регулярно проверяйте согласованный график поставки. Вместо того, чтобы проверять ход выполнения работ, лучше периодически спрашивать: «Есть ли какие-либо причины, по которым вы не сможете выполнить свои обязательства?»

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

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

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