Почему скрам-мастер и менеджер проекта не могут быть одним и тем же человеком?

Scrum проводит различие между поддержкой команды в том, ЧТО они делают и КАК они это делают. Попытка сделать так, чтобы один человек играл в обе игры, привел бы к большому конфликту. Что вы выбираете в стрессовой ситуации: обсуждать фичи или помогать команде расти и достигать консенсуса? Скрам-мастер — это фасилитатор, как он/она может фасилитировать, если он тоже владеет проектом?

«Роли Владельца Продукта и Скрам-Мастера дополняют друг друга. Владелец Продукта в первую очередь отвечает за «что» — создание правильного продукта. Скрам-мастер в первую очередь отвечает за «как» — правильное использование Скрама. Правильный продукт создается с помощью правильного процесса — достигается устойчивый успех». –Роман Пихлер, «Управление продукцией Agile с помощью Scrum»

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

http://skipstoneconsulting.blogspot.com/2011/12/identifying-with-titles-or-what-happens.html

Таким образом, чтобы конкретно ответить на вопрос «Почему скрам-мастер и менеджер проекта не могут быть одним и тем же человеком»? это потому, что вы не можете (не должны) просить одного человека нести ответственность за то, КАК команда выполняет свою работу и ЧТО она делает, потому что под давлением бизнеса человек уступит или отдаст предпочтение одной стороне спектра. Скорее всего, часть «Что». С некоторыми из них, наблюдающими за «высоким», вы гарантируете, что качество, хорошая командная практика и многое другое также получают внимание, необходимое для поддержания здоровой работоспособной команды, в то время как другие сосредоточены на том, чтобы здоровая работающая команда стала хорошо сфокусированной. ввод и видение из одного источника.

Почему скрам-мастер и владелец проекта не могут быть одним и тем же человеком?

Это просто конфликт интересов и направленности. Основное внимание владельца проекта сосредоточено на успехе проекта и его реализации, однако главное внимание скрам-мастера сосредоточено на команде и ее развитии. Два разных дела, которые не могут быть успешно выполнены одним человеком одновременно.

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

Чем они отличаются от традиционных менеджеров проектов?

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

Скрам-мастер отвечает за создание среды, в которой команда общается честно и прозрачно и делает все возможное. Это также предоставляет данные, с которыми может работать менеджер проекта.

Руководитель проекта несет ответственность за успех проекта.

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

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

Если все сделано правильно, Scrum рано обнаружит марш смерти или увеличение бюджета. Это часто находится в прямом противоречии с целями руководителя проекта, и именно поэтому роль скрам-мастера полезна.

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

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

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

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

Скрам-мастер и менеджер проекта не должны быть одним и тем же, потому что команда должна чувствовать, что они подотчетны команде (а не скрам-мастеру). Ежедневные стендапы — это отчеты для команды (а не для скрам-мастера). Скрам-мастер должен устранять препятствия и помехи, а не управлять командой — команда самоуправляема.

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

Расширение прав и возможностей Команды Разработки является важным ядром Scrum. И владелец продукта, и скрам-мастер должны понимать, что их самая важная задача — не мешать команде и позволять или даже заставлять команду учиться решать собственные проблемы.

• Владелец продукта несет ответственность перед заинтересованными сторонами за содержание невыполненной работы и ценность, предоставленную командой.

• Скрам-мастер - это ресурс команды в отношении правил Скрама, а также помогает гарантировать, что менеджеры, заинтересованные стороны, PO и сам SM не вмешиваются в способность команды к самоорганизации.

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

Традиционные/иерархические названия должностей, такие как «менеджер по продукту» (или «руководитель разработки»), не имеют отношения к Scrum и должны игнорироваться командой. Эти люди могут быть PO или SM, а могут и не быть. При выборе «менеджеров» или «руководителей» на роли Scrum существует определенный риск, заключающийся в том, что команда может иметь привычку уступать этим людям, что подрывает самоорганизацию. В таком случае необходимы значительные усилия для того, чтобы команда управляла собой и брала на себя ответственность за свою работу!

Менеджер проекта — это всезнающий мужчина/женщина, которые находятся во власти и говорят вам, что делать, и вы ненавидите их из-за этого.

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

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

Теперь серьезный ответ.

Если вы готовы принять определение «менеджер проекта» как человека, который применяет знания, навыки и методы для выполнения требований проекта, скрам-мастер — это PM. «Содействие» и «власть над процессом» — это управление, обеспечивающее выполнение требований. Если вы хотите сузить определение, вы не согласны с «промышленностью» (я получил определение от PMI).

Scrum — это фреймворк Agile-процессов. Люди забывают, что Agile-проект ограничен по времени и стоимости. Agile-проекты делают не заранее Scope, а то, что позволяют время и стоимость. Вы просто расставляете приоритеты в объеме (отставании) в соответствии с ценностью для бизнеса и молитесь о том, чтобы было достигнуто достаточное удовлетворение, чтобы оно считалось «успешным». Agile появился потому, что в некоторых проектах (программных проектах) много неопределенности, и было установлено, что лучший способ справиться с неопределенностью — это быстро ее устранить. Вы можете предположить, что «менеджер проекта» никогда не работает в такой среде, и вы ошибаетесь.

Иногда человек с PM в качестве должности может быть просто Scrum Master для не Agile-проекта. Они не принимают никаких решений. Они облегчают процесс. Они их, чтобы "устранить препятствия". Они не определяют и не выполняют никакой фактической работы. Единственная власть, которую они имеют, касается процесса управления проектом. Иногда они могут делать больше, так же как Скрам-мастеру, возможно, придется выйти за пределы своей роли и сделать больше.

Одно из ключевых различий между PM и Scrum Master заключается в том, что PM настраивает процесс под проект. Фреймворк Scrum кажется фреймворком управления проектами «раскраски по номерам» для небольших команд разработчиков программного обеспечения, а раскрашивание за пределами границ считается «плохим».

если вы видите проблему с точки зрения конфликта, фокуса, разных целей, ЧТО, КАК и сегрегации, да, SM и PO не могут быть одним и тем же человеком, если у него нет раздвоения личности.

но, если вы видите вещи из совместной командной работы, взаимной компетенции и страсти к созданию ценности для клиента (Agile), я не вижу смысла, почему SM и PO не должны быть одним и тем же человеком.

если вы посмотрите на микроуровне с точки зрения задач и обязанностей, то да, это огромная разница. но если смотреть с макроуровня, перспективы значительно меняются. это вопрос мнения, где вы устанавливаете свою точку зрения. Я усвоил этот урок от отличного чувака, который на самом деле создает нечто для Agile-сообщества, которое оно называет «законом чувака».

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

Существует должность, которая сочетает в себе аспекты менеджера проекта и скрам-мастера в среде Agile. Правительство Великобритании использовало роль менеджера по доставке ( https://gds.blog.gov.uk/2012/12/12/a-day-in-the-life-of-a-delivery-manager/ ). Digital Services и другие организации в течение ряда лет.

Роль менеджера по доставке выполняет роль слуги-лидера, стендапа и других церемониальных аспектов мастера схватки, а также аспектов планирования проекта PM.

http://itsadeliverything.com/delivery-manager-a-new-role-for-an-agile-world

ИМХО, Короче говоря, у них разные обязанности, и роль Scrum Master не фиксирована, в то время как Product Owner обычно остается одинаковым для каждого продукта.

По большому счету, в случае провала продукта будет виноват Владелец Продукта, а Скрам-мастер тут ни при чем.

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

Поэтому я предпочитаю говорить о:

1. менеджер проекта : лицо, ответственное за принятие всех управленческих решений.
2. команда : те, кто выполняет работу.
3. клиент : те, кто платит деньги за выполнение проекта.

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

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

Я предпочитаю более легкую, самодельную модель, которую любой может согласовать после встречи.

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

Я научился доверять своим способностям, как и всем нам, и способностям членов моей команды, особенно в том, что касается инноваций и своевременного выполнения работы, но в основном в совместном согласовании того, как это сделать. Мне так весело работать таким образом.

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

В ходе учебы я усвоил основные аспекты управления в любой ситуации:

1) Планирование : что вы собираетесь делать и с какими ресурсами.

2) Организация : объединение людей с материальными ресурсами для выполнения работы.

3) Направление : Ведение команды через процесс от начала до конца.

4) Оценка : постоянная обратная связь для оценки достижения целей, поставленных на первом этапе.

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

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