Одно из препятствий на пути к готовому — бутылочные горлышки и блоки (пробки). Стефани Окерман говорила об этом в своем предыдущем материале.

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

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

Порой мы погружаемся в иллюзорные ожидания: давайте сделаем больше фич, давайте сделаем их быстрее. Мы откладываем совершенствование имеющегося на потом, а ведь это “потом” может никогда не наступить.

Уделяйте внимание блокам. Это поможет усовершенствовать рабочие процессы, обеспечить более высокое качество и упростить введение улучшений в долгосрочной перспективе.

А вот и пять распространенных вызовов, с которыми сталкиваются команды при попытках разбивать блоки на своем пути.

1. Команде не хватает полномочий

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

Что можно сделать?

  • Дайте разработчикам больше ответственности. Ведь качество продукта зависит от того, как именно они наполняют бэклог продукта инкрементами ценности. От их экспертности зависит, как хорошо это получается. Так что именно они должны управлять и совершенствовать собственные процессы, инструменты и взаимодействия, чтобы эффективнее организовывать поставку ценности.
  • Коучите менеджмент касательно создания среды, в которой команда сможеть брать на себя полномочия.
  • Задавайте вопросы, как именно стоит работать. Это может касаться процессов и практик, которыми владеет команда, или еще чего-то в организации. Смелые вопросы могут помочь команде взять на себя ответственность.
  • Просите прощения, а не разрешения. Скрам-мастер может показать пример команде, если она пока что не чувствует себя достаточно уполномоченной. И он же должен быть готовым защитить команду во время ее первых попыток брать на себя полномочия.

2. Мы путаем ограничения и предположения

Часто люди считают, что должны следовать определенным процессам или использовать конкретные инструменты, потому что это ограничение их организации.

На тренинге Professional Scrum Master мы говорим о том, что ограничения помогают максимизировать самоорганизацию

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

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

Сомневайтесь во всем.

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

Одна из таких диких идей может перерасти в совершенно рабочую гипотезу.

3. Мы не понимаем реального влияния блоков

Случаются ли в вашей команде повторяемые блоки? Как сильно они влияют на вашу работу?

А может, ваша команда откладывает улучшение процессов или инструментов на потом, потому что они будут требовать значительных усилий? Или вы боитесь, что это чересчур дорого и вас не станут финансировать?

Откладывает ли ваша команда обучение или менторинг из-за нехватки времени? Может, они боятся показаться менее продуктивными?

Вот два способа определить реальное влияние блоков:

  • Смотрите шире: не только на блоки, а и на ситуации, в которых они срабатывают, и на их долгосрочное влияние. Большинство блоков работу не останавливают, а ограничивают, как ограничивают и способность команды поставлять ценность. Мы называем эти блоки “якорями”. С ними команда может двигаться дальше, но будет тащить их за собой. Когда команда устанет, ее движение еще больше замедлится.
  • Трансформируйте влияние команды в числа: высказывайтесь в бизнес-категориях. Пускай они будут заметными. Повесьте на доску. Тренды должны бросаться в глаза.

— Сколько времени мы тратим на борьбу с блоком? Как часто возникает этот конкретный блок? Стефани Окерман советует попробовать технику расчета расходов Waste Snake.

— Как блок влияет на качество? К примеру, количество дефектов на производстве растет или падает? Сколько стоит исправить дефект на производстве, а сколько — на этапе разработки?

— Как это влияет на гибкость команды?

— Как блоки влияют на мораль? Уходят ли люди из компании, потому что блоки мешают им работать? Сколько стоит наем новых сотрудников? (Вроде бы как бы это слишком, но селяви. Полезные люди уходят из дисфункциональных организаций. А толерирование блоков — это как раз дисфункция.)

Не ждите, пока блок приобретет статус срочного (то есть, когда всякое движение вперед станет невозможным без удаления блока). Это еще увеличит ваши потери.

4. Слишком распланированный спринт

Планировать каждый рабочий час каждого члена скрам-команды во время спринта — ошибочная практика, ведущая к провалу. Команда будет чувствовать себя так, будто у нее просто нет времени на убирание блоков. Пора понять: усовершенствование — это часть работы. Вот несколько идей, как принять и поддержать этот процесс в команде.

  • Прекратите ставить им дедлайны в форме ультиматума и задавать фиксированный объем работ. Чтобы поставлять серьезный функционал в заданные сроки, команда может подналечь на разработку элементов продуктового бэклога и отложить в сторону улучшения, необходимые для повышения ее эффективности. Скрам-мастера и владельцы продукта могут помочь защитить разработчиков от этого давления и поработать со стейкхолдерами снаружи команды, которые это давление создают.
  • Добавьте блокам наглядности и озвучьте их на планировании спринта. Порой разработчики и владелец продукта должны буквально видеть блоки, чтобы не забывать о них на планировании. Если влияние блоков понятно, следующим шагом будет визуализировать их и рассмотреть на планировании спринта.
  • Склоните владельца продукта на свою сторону. Ответственность владельца продукта состоит в максимизации ценности продукта. Если продукт не масштабируется, не улучшается или не может содержаться в качественном состоянии, владелец продукта никак не извлечет из него больше ценности (либо же это будет ему дорого стоить). Мы знаем многих Продакт Оунеров, которые яростно выступали в защиту постоянного совершенствования.
  • Не бойтесь говорить о блоках на обзоре спринта. Какие-то вещи, конечно, стоит уладить со скрам-командой на ретроспективе. А не ревью можно поднимать вопрос об организационных блоках или препятствиях, решение которых требует инвестирования в скрам-команду. Это событие посещают многие стейкхолдеры, а значит, они могут повлиять на более быстрое решение ваших проблем.

5. Менеджмент не привлекается к устранению организационных блоков

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

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

А еще эта тема поднимается и обсуждается на сертификационном тренинге Scrum.org Professional Scrum Product Owner

Подытожим

Скрам-команда должна устранять препятствия.

Это помогает повышать ее эффективность в поставке ценного программного обеспечения.

Скрам-команда должна обладать полномочиями к устранению препятствий.

Влияние блоков на рабочий процесс должно быть прозрачным.

Скрам-команде нужно давать время на устранение препятствий.

Самоорганизованная команда сама знает, какие препятствия устранять, в каком порядке и когда требуется помощь извне команды.

Источник: scrum.org.