Я ScrumMaster для команды разработчиков и QA с владельцем продукта.
В течение последнего года я безуспешно пытался заставить ОП понять, в чем заключается роль ОП, но он, кажется, просто не понимает этого. Он пробует мои предложения в течение нескольких недель, а затем переходит к своему прежнему режиму работы, особенно когда приближаются сроки:
Что сказала команда:
Мой вопрос в том, куда мне идти отсюда. Я на пределе своих возможностей.
Я подумал, что моим следующим шагом должен быть разговор с его менеджером и объяснение, что я думаю, что он станет очень хорошим традиционным менеджером или руководителем проекта, но я не вижу никаких качеств, полезных для владельца продукта.
Есть несколько областей, в которые я хотел бы углубиться.
Во-первых: почему команда терпит это от PO. PO, SM и команда должны иметь примерно равные полномочия в команде Scrum, хотя и в разных областях. Я предполагаю, что есть некоторые другие факторы, которые дают PO больше полномочий.
Я часто смотрю на Скрам-команду как на перетягивание каната. Пока роли тянут примерно одинаково, возникает естественное напряжение и нам всем весело. Если какая-то из ролей слишком сильна или слишком слаба, все падают.
Во-вторых: Каково давление на ПО? У всех нас есть ожидания от нас на работе, но если компания ожидает объем X к дате поставки Y и возлагает ответственность за это на PO, у вас есть ситуация, в которой PO не может выполнить работу, и это вредно для всей команды Scrum. . В большинстве команд, с которыми я работаю, мы определяем цель команды и критерии успеха. Как только мы видим, что мерой является «выполнить работу», мы понимаем, что у нас есть проблема. Меры должны быть сосредоточены на прибыльности, снижении затрат, удовлетворенности пользователей и т. д. Затем задача PO состоит в том, чтобы максимизировать тех, какую работу может выполнить команда. Обычно в таких ситуациях, как вы описываете, запросы на заказ от других в компании являются неверными ожиданиями.
Я подозреваю, что у вас проблемы с выравниванием и балансом, а проблема с практикой вторична, тем более что вы говорите, что ПО пробует предложения, а затем под давлением возвращается к старым привычкам.
Ответ здесь действительно зависит от того, насколько команда способна использовать Scrum.
Я вижу здесь несколько вещей, которые, возможно, стоит распаковать вместе с вашим заказом на покупку:
Daily Scrum предназначен для команды разработчиков, чтобы перепланировать свой день, чтобы достичь цели спринта. Если PO мешает, он не должен присутствовать, поскольку это отвлекает от цели Daily Scrum. Следует приложить усилия, чтобы научить PO полезности Daily Scrum.
PO несет ответственность за максимизацию/оптимизацию ценности выполненной работы, а НЕ за выполнение указанной работы. Команды разработчиков структурированы и уполномочены организацией организовывать и управлять своей собственной работой. Опять же, это звучит как возможность коучинга с вашим PO.
заказ на покупку должен быть доступен, чтобы внести ясность в рабочие элементы. Если они не могут этого сделать, скрам-мастер должен научить их тому, как стать лучше в этом. Если ситуация не улучшится, следует обсудить возможности внешнего обучения.
В целом, это похоже на разговор, который нужно вести во время ретроспективы спринта, а не один на один, когда прозрачность ограничена. Научить команду воплощать ценности Scrum во время этого мероприятия, в частности Открытость и Смелость, легче сказать, чем сделать, но это необходимо для устранения причинно-следственных связей и обеспечения прозрачности как внутри, так и снаружи команды. Жесткие разговоры продвигают команду вперед.
Если план исправления вытекает из этого открытого разговора, а прогресса нет, то имеет смысл выйти за пределы команды. Устранение препятствий для прогресса команды и помощь заинтересованным сторонам организации в понимании и внедрении Scrum и эмпирической разработки продуктов являются ключевыми элементами работы Scrum Master. Трудная задача, но неотъемлемая часть роли.
Все ответы выше действительны. Я просто хотел бы упомянуть, что единственное «оружие», которое может использовать команда, — это тщательно отслеживаемый и классифицированный журнал отходов. Отслеживайте ожидание, доработку, обслуживание долга, перепроектирование и т. д. и сообщайте о времени (т.е. деньгах), потраченном впустую из-за недостаточного процесса. Затем предложите пункты действия. Это единственный способ, который я нашел действительно работающим, когда аргументы здравого смысла не работали. Работа есть работа, поэтому отслеживать время, потраченное на работу, бессмысленно. Отслеживайте время, проведенное на блокировщиках. Проверьте https://dzone.com/articles/90-sprints-for-capital-markets-part-4-of-4 (отказ от ответственности - я автор)
нвоигт
Эрик