Владелец продукта, с которым я работаю, согласился «попробовать эту самоорганизующуюся штуку» в нашей Scrum-команде.
Короче говоря, я убедил ее, что у команды есть два пути. Один, в котором она направляет и управляет командой, но также в значительной степени берет на себя ответственность за результат и содержание, или, альтернативно, мы можем работать вместе, чтобы создать самоорганизующуюся команду, чтобы взять на себя ответственность и ответственность. Она согласилась попробовать последнее.
Кто-нибудь пробовал это или может порекомендовать метод для обучения и обучения этой концепции Владельцу Продукта, который открыт для изменений, но очень доминирующий и директивный над командой.
Я думал просто наметить все ее поведение на Миро и объяснить, какое поведение способствует тому, какой тип команды. например, постоянное напоминание команде сделать x,y,z приводит к тому, что они никогда не берут на себя полную ответственность за x,y,z. и т. д.
Хотя это похоже на психологический вопрос и не имеет отношения к методологиям, я не согласен, что это тупиковый путь, и вы не можете изменить поведение людей. Но сначала вам нужно понять основные причины такого поведения, которые могут быть:
Как только вы поймете, что лежит в основе этого «властного» поведения, вы сможете придумать план, как это исправить. Некоторые решения, которые могут работать для некоторых людей:
В любом случае, я бы поэкспериментировал. Я думаю, что очень важно, чтобы команда очень хорошо понимала предметную область, чтобы этот план был успешным.
Но я также был бы осторожен, чтобы не переоценить команду. Вы продолжаете слышать о самоорганизующихся/самоуправляемых командах, как будто это хорошо и мы должны к этому стремиться. Но большинство команд (по крайней мере, из того, что я видел) по своей природе не способны к самоорганизации. И движение в этом направлении может замедлить процесс и, следовательно, оттолкнуть людей, которые действительно способны хорошо выполнять свою работу (возможно, это ваш заказ).
Нет, нет, нет. Просто нет."
Вопрос основан на ошибочном предположении, что вы можете навязать изменения другим людям (подсказка: вы не можете), и желает того, что, вероятно, будет плохим составом команды на кукурузном поле.
Владелец продукта, с которым я работаю, согласился «попробовать эту самоорганизующуюся штуку» в нашей Scrum-команде.
Это красный флаг, который говорит вам о том, что человек, которого вы назвали «властным», готов помахать рукой, чтобы принять agile, или удовлетворить просьбу, фактически не придерживаясь ни одной из ценностей Scrum или agile. Это не прочная основа для изменений.
Вы задаете вопрос, который ab initio предполагает , что есть некая серебряная пуля, которая позволит вам изменить этого человека, который в настоящее время не подходит для членства в Scrum-команде. Владелец продукта — это член команды с определенными обязанностями , а не авторитарный диктатор, избранный на всю жизнь. В Руководстве по Scrum говорится:
В Скрам-команде нет подкоманд или иерархий. Это сплоченная группа профессионалов, сосредоточенных на одной цели за раз, на Цели Продукта... Скрам-команда... структурирована и уполномочена организацией управлять своей собственной работой.
Таким образом, любая постановка проблемы, которая не начинается там, обречена стать интермедией эпических масштабов, полной драмы и слез. Только владелец продукта может изменить свое поведение, и для этого он должен захотеть измениться. Без этого - пустая трата времени.
Правильные вопросы:
Не задавайте эти вопросы только себе. Как скрам-мастер, вы должны иметь целеустремленность, сосредоточенность, открытость, уважение и смелость, чтобы задавать эти вопросы всем участникам, как по отдельности, так и вместе. Это не ваша проблема; это проблема Скрам-команды, и если оставить ее нерешенной, то это проблема организации.
У владельца продукта есть четко определенная роль (произносится как «ответственность» в Руководстве по Scrum 2020), и Scrum-команда должна работать вместе над разработкой внутренних рабочих соглашений, которые поддерживают (но не противоречат) требованиям фреймворка. Это означает, что «властное» поведение должно быть:
Как скрам-мастер, вы можете и должны тренировать этого человека как можно больше. Объясните роли/обязанности, помогите им как можно лучше понять agile-принципы , Scrum Theory и Scrum Values , и даже дайте им домашнее задание по agile-практикам и кейсам, если найдете что-то подходящее. Однако...
Скрам-мастер — это не просто пассивный лидер-слуга. Руководство по Scrum 2020 ясно дало это понять. В обязанности скрам -мастера входит:
Скрам-мастер несет ответственность за создание Скрама, как это определено в Руководстве по Скраму. Они делают это, помогая всем понять теорию и практику Scrum, как внутри Scrum Team, так и в организации.
Скрам-мастер отвечает за эффективность Скрам-команды. Они делают это, позволяя Скрам-команде улучшать свою практику в рамках Скрам-фреймворка.
Таким образом, если вы не считаете владельца продукта (и остальную часть команды Scrum) ответственными за эффективное сотрудничество в рамках Scrum, то вы также не выполняете свою роль должным образом. Ваша задача состоит в том, чтобы научить их основам, помочь им применить структуру к своим проблемам и процессам, а также привлечь внимание высшего руководства к непреодолимым проблемам с составом команды. На самом деле, в Scrum Guide 2020 говорится (выделено мной):
Скрам-мастер служит организации несколькими способами, в том числе:
- Руководство, обучение и коучинг организации по внедрению Scrum;
- Планирование и консультирование по внедрению Scrum в организации;
- Помощь сотрудникам и заинтересованным сторонам [включая руководство] в понимании и применении эмпирического подхода к сложной работе; и,
- Устранение барьеров между заинтересованными сторонами и Scrum-командами .
Последнее особенно важно. Проблемы с составом команды (во многих организациях) находятся вне контроля Скрам-команды. Следовательно, проблемы, которые не могут быть решены внутри команды посредством самоуправления и сотрудничества, должны быть видны организации , а ответственность за исправление проблем с составом команды или решение кадровых вопросов в конечном итоге лежит на руководстве организации.
Как скрам-мастер, вы должны иметь мужество и целеустремленность, чтобы поднимать эти вопросы, когда это необходимо. Если Scrum-команде в целом не хватает навыков, приверженности или готовности решать проблемы с коммуникациями и решать проблемы напрямую, то Scrum дает четкие указания, что делать: обеспечить прозрачность и видимость проблемы для организации , а затем удерживать руководство организации несет ответственность за решение вопросов, которые уполномочены решать только они.
Во что бы то ни стало, работайте с владельцем продукта и разработчиками, чтобы сделать проблемы видимыми и наладить сотрудничество, где это возможно, но ваша задача — не погибнуть на холме межличностных конфликтов внутри команды. Объясните процесс, направьте команду в применении процесса и помогите команде адаптировать процесс, но, в конце концов, каждый член Скрам-команды несет полную ответственность за свое эффективное участие (или его отсутствие) в процессе. Вы не можете заставить их сделать это или даже заставить их хотеть это сделать.
Scrum — это не серебряная пуля. Он не может с помощью магии превратить несамореализующихся людей в сплоченную высокоэффективную команду. Это требует приверженности и тяжелой работы всей команды, а также определенного уровня внутренней мотивации от членов команды. Ваша основная задача в этой ситуации — определить, гора это или мука слона, а затем помочь команде и организации исследовать пространство решений, пока все не согласятся на эксперимент или план действий, отвечающий интересам команды в целом. , текущий проект и организация.
В отличие от Барнаби, я бы предложил сосредоточиться на том, что от нее нужно, а не на том, что от нее проблематично. (Или объединить два подхода.)
Изучите Руководство по Scrum всей Командой, уделяя особое внимание разделу об обязанностях ролей. Затем, если/когда она начнет заявлять о своем присутствии в Команде (таким образом, что это не совсем правильное утверждение), попросите ее оправдать это.
«Можете ли вы объяснить, как именно это относится к тому, что вы представляете потребности клиента?»
«Это не так, но нам все равно нужно знать о влиянии на проект».
«Спасибо, тогда мы примем это к сведению при принятии решения. Что-нибудь еще?»
Что, конечно, также оставляет место для случая, когда:
«Можете ли вы объяснить, как именно это относится к тому, что вы представляете потребности клиента?»
«Клиент специально просил избегать использования гибких виджетов».
"...Почему?"
«Мне придется перепроверить, но я думаю, потому что они несовместимы со своими серверами?»
— Ладно, перепроверьте, пожалуйста, а пока мы попробуем придумать что-нибудь еще.
Ключевым моментом будет найти способы подчеркнуть влияние микроуправления владельца продукта. Если вы не можете продемонстрировать влияние, мало что может помешать им вернуться к своим старым привычкам.
Например:
«Салли была заблокирована сегодня, так как они ждали, когда владелец продукта решит, что делать дальше. Если бы они могли принять это решение самостоятельно или вместе с командой, это могло бы сэкономить нам несколько часов».
Как уже упоминалось, вы не можете убедить доминирующую личность не доминировать.
Я также не уверен, что она видит мир так, как ты, а именно:
Один, в котором она направляет и управляет командой, но также в значительной степени берет на себя ответственность за результат и содержание, или, альтернативно, мы можем работать вместе, чтобы создать самоорганизующуюся команду, чтобы взять на себя ответственность и ответственность .
Т.е. что раз она "микроуправление", то она и отвечает за последствия, а если она "отпускает", то ответственность несет команда.
Я подозреваю, что вы можете сделать предположение.
Она может считать себя ответственной в любом случае или не понимать, почему она несет ответственность в любом из сценариев — это также зависит от ее личности.
Как только вы проясните ее мировоззрение по этому поводу, вы сможете попытаться улучшить ситуацию.
Если она считает себя ответственной «несмотря ни на что», то вы должны доказать ей, что предоставление вашей команде необходимой свободы действий принесет ей лучшие результаты.
Если она возлагает ответственность на команду, то вам предстоит более сложная работа; пытаясь убедить ее, что она главная, при этом обретая некоторую независимость. Вы находитесь в прямом конфликте со всей ее личностью.
Хорошо, я просто еще раз добавлю свой «ответ, за который проголосовали против».
«Вы программный проект. Удачи вам. Вы организуете себя или самоорганизуетесь, как хотите. Удачи вам».
«Вы не являетесь владельцем продукта !»
Владелец продукта — это важнейшее связующее звено между всем процессом разработки и бизнесом, который за это платит. И хотел ли я упомянуть, что: «бизнес не знает, не понимает или не заботится?»
Роль владельца продукта — это гораздо больше, чем просто роль «прокси». Роль владельца действительно роль Януса – «двуглавого бога». Это роль, которую часто неправильно понимают «те, кто лежит ниже», и этой роли нельзя позавидовать. Хозяин - это тот, кто тебя защищает .
Выше вашей команды «бизнес» будет привлекать к ответственности владельца. И «владелец» возьмет на себя эту ответственность, так что — намеренно — никому из вас не придется. Но ответственность все же есть.
Станислав Башкирцев
пользователь32613
Тодд А. Джейкобс
пользователь32613