Часто слышу вопрос о совмещении ролей ScrumMaster (SM) и Product Owner (PO).Как по мне, то это крайне нежелательно.
Причины:
Одной из задач SM является следить за правилами выполнения "игры Scrum" и помогать команде и заказчику (в частности PO) эффективно работать. То есть выполнять наибольшее количество business-value за единицу времени, но при условии поддержки определенного уровня качества (!)
PO не всегда видит и понимает значение внутреннего качества продукта, поэтому зачастую присутствует противостояние между командой и PO. Звучит это так: "что лучше - продавать больше фич (писать быстрее и больше) или же писать меньше, но качественнее (т.е. медленнее)".
Наличие этого противостояния - это показатель здоровья проекта. Никто не должен в итоге уйти победителем. Либо они находят компромисс и все выигрывают, либо же все проигрывают.
Так вот, SM, работая на стороне команды следит за тем, чтобы не было явного перекоса в ту или иную сторону в течение долгого времени. В этом как по мне и состоит его основная обязанность.
Еже ли SM и PO - одно и то же лицо, то у этого человека будет явный внутренний конфликт, и этот баланс скорее всего очень быстро закончится, и перевесит сторона PO (читать "сиюминутная прибыль").
К тому же, SM также выполняет роль "защиты от шумов", предотвращая на сколько это можно сильные изменения приоритетов требований внутри спринта. Но так как эти шумы чаще всего исходят от PO, то опять таки совмещая эти роли, этот человек вряд ли сможет адекватно балансировать ситуацию в течение долгого периода времени.
Так что, если вы попали в ситуацию, когда вы PO и сами же внедряете Scrum - то лучше будет как можно скорее вырасти одного (а лучше несколько хороших) SM-ов, которые будут в тяжелые минуты помогать тебе принять сбалансированные решения. Они будут вашей совестью в сложных решениях, и работая тесно на стороне команды принесут больше пользы, чем могли бы принести вы, работая SM на полставки.
Удач!
Кривицкий А.
В реальной жизни эти роли действительно очень плохо совместимы - причём "спецеффекты" такого совмещения могут быть и другими. в конечном итоге страдает проект, изза отсутствия баланса.
ReplyDeleteЯ согласен, что разнести эти роли по двум разным людям полезно. Но ничего страшного в совмещении этих ролей в одном человеке я не вижу. Я предлагаю концепцию "шляп". Надо знать, когда ты в шляпе Scrum Master'а - и в этом состоянии ты чувствуешь и думаешь, как Scrum Master. Также ты можешь осознанно переключиться в роль Product Owner'а - и нося эту "щляпу", ты думаешь и чувствуешь, как Product Owner. И, разнеся эти состояния во времени, можно избежать внутреннего конфликта, о котором ты говоришь. Главное - научиться переключаться. Уолту Диснею удавалось переключаться между тремя состояниями - "Мечтатель", "Реалист" и "Критик". Точно так же можно научиться менять шляпы, переключаться между ролями PO и SM. Но, без сомнения, разделять между двумя людьми - удобнее.
ReplyDeleteАлексей Тигарев
Я недавно беседовал с человеком, который представился как СКРАМ практикующий. После ответа на вопрос кто у него был ПО, а кто СМ, выяснилось что это одно и то же лицо.
ReplyDeleteЯ себе представил картину: человек предстваляет продукт команде в начале итерации в виде бэклога, потом они вместе формируют спринт, включая туда инфраструктурные задачи и после этого каждый день следит за прогрессом и решает проблемы (impediments) команды.
Конечно если напрячь фантазию то можно себе представить очень разумного заказчика, который, беседуя с командой, понимает необходимость включения в TODO лист и готов разбираться и решать все проблемы технического и нетехнического плана, которые команда решить не в состоянии, но есть две вещи:
1) Практически роль скрам мастера достаточно рутинная, даже если команда очень квалифицированная и состоит всего из 4 человек текущих вопросов в СМ-бэклоге накапливается выше крыши. Можете поспрашивать практикующих скрам-мастеров. Случай с тем парнем, которого я собеседовал не считается: он вообще говоря был один в команде ...
2) Предположим что наш СМ-ПО гений и с потоком задач справляется. Но разве это не вырождает Скрам? Зачем вообще формировать спринт, когда ПО и так в курсе о состоянии проекта в каждый момент времени? Не проще ли просто обозначать список задач и согласовывать с командой декомпозицию этих задач и оценки по мере надобности или возможности? И не вести переговоры на тему изменения scope, когда ПО и так понимает что его лучше изменить?