Я член команды в Scrum-команде. Этим утром у меня была беседа со скрам-мастером, в ходе которой я сказал, что мне нужны два человека из другой команды, чтобы они стали частью моей команды. Я сказал, что хотел бы обсудить это с владельцем продукта, а затем с менеджером. Скрам-мастер в основном изменил обсуждение, заявив, что ответственность за это лежит не на мне и не на Владельце продукта, а на скрам-мастере.
Кто отвечает за изменение состава Скрам-команды?
Это интересный вопрос, потому что он затрагивает некоторые тонкости самоорганизации с помощью гибких фреймворков. В частности, он подчеркивает различия между властью и влиянием .
Члены Скрам-команды несут ответственность за выявление препятствий (например, у команды нет достаточного опыта в проектировании баз данных) и рекомендации по адаптивным улучшениям (например, предложение, чтобы Джон Доу, администратор баз данных, мог предоставить опыт, которого не хватает команде). Члены команды также несут ответственность за влияние на состав команды, давая рекомендации по добавлению или удалению людей из команды.
Владельцы продукта (часто) несут ответственность за бюджетирование ресурсов. В таких случаях владелец продукта будет нести ответственность за утверждение или отклонение ресурсов, которые будут включены в его бюджет. Это прямо входит в основную обязанность Владельца Продукта по установлению приоритетов проекта.
Скрам-мастера несут ответственность за содействие обсуждению ресурсов проекта (включая ограничения ресурсов), препятствия процесса и рекомендации по улучшению процесса. Однако скрам-мастерам обычно не хватает полномочий для непосредственного внедрения организационных изменений. Когда Скрам-команда согласовывает подход, Скрам-мастер несет ответственность за то, чтобы рекомендации команды дошли до соответствующих лиц, принимающих решения, и за продвижение интересов команды в более крупной организации посредством влияния .
Если скрам-мастеру не были предоставлены дополнительные полномочия, выходящие за рамки обычной роли, он не должен принимать решения о найме или распределении ресурсов в одностороннем порядке. Это не является общепринятой практикой Scrum и, конечно же, не отвечает интересам построения команды; тем не менее, это иногда происходит в определенных типах организаций.
Вы совершенно правы, когда высказываете свои опасения и рекомендации внутри команды, но совместная ответственность Скрам-команды заключается в согласовании решения и представителя . Однако решение о том, какие люди или ресурсы нужны команде и как команда может наилучшим образом помочь Скрам-мастеру в представлении интересов команды перед остальной частью организации, совершенно точно не входит в ваши полномочия.
Организационные полномочия, будь то от имени компании или команды Scrum, всегда должны быть делегированы. Скрам-мастер был бы совершенно прав, пометив члена команды, использующего односторонний подход к этому вопросу, как выходящий за рамки общепринятых практик фреймворка.
Первый из Манифеста Agile звучит так: «Люди и взаимодействие важнее процессов и инструментов». Это означает, что никто не должен отчаиваться от устранения препятствий, говоря, что это не его роль . Особенно, если есть реальный импульс для достижения цели.
Если вы хотите поближе познакомиться с «правилами», то каждый из членов команды должен уметь поднимать риски и препятствия и предлагать решения и планы по их устранению. Если команде не хватает навыков или знаний, это также повлияет на способность команды достигать целей. Это звучит как препятствие PO, а также.
Устранение препятствий является обязанностью скрам-мастера, потому что члены команды и PO часто сильно сосредоточены на получении результатов, поэтому должен быть кто-то, кто также заботится о производительности другой команды , поскольку их ресурсы будут (фактически) ограблены. Тем не менее, я с трудом представляю себе SM, которому удалось бы изменить размер команды без активной поддержки команды.
Если я правильно понял ваш вопрос, поскольку ваша команда пытается добавить ресурсы, то вы поступаете правильно, однако, если вы один решили внести такую корректировку, боюсь, это не ваш вызов, а команда. В Scrum команды совместно принимают такие решения, поэтому, если вы считаете, что вам нужно два ресурса, лучше указать это как препятствие в ежедневном Scrum и после Scrum обосновать перед командой и SM причины, по которым вы намерены это сделать. В скраме команда имеет право вносить коррективы в настройку команды, однако скрам-мастер может контролировать, делаете ли вы правильные вещи или нет. Например, ваша команда состоит из 6-7 человек, и вы добавляете еще несколько ресурсов, вы рискуете аспектами коммуникации, потока и т. д. Конец дня PO отвечает бизнесу за рентабельность инвестиций к концу спринта. Он мог бы финансировать проект, если это так, как Адриан выше предполагает, что это его последний призыв добавить ресурсы, поскольку это может повлиять на стоимость. Если эти два ресурса являются общими ресурсами для других команд, то это не должно требовать одобрения PO, возможно, это потребует исполнительного PO для всей платформы. Когда у вас есть общие ресурсы, лучше проводить собрания по планированию кластерных спринтов, на которых задействованы общие ресурсы.
Давайте немного рационализируем: - Это определенно не вызов PO, он отвечает за управление продуктом, а не командой (которая является самоуправляемой), но, конечно, он распоряжается бюджетом, так что это косвенное требование к структуре команд. - Скрам-мастер должен поддерживать команду в режиме высокой производительности, поэтому его подход должен быть таким: я вижу, что вам не хватает мускулов, давайте рассмотрим возможность добавления еще Х парней в нашу схватку.
Но это должен быть вызов команды о добавлении еще одного члена команды и о том, кем должны быть эти члены команды, поскольку команда должна чувствовать себя комфортно с добавлением.
Теперь о сроках: ретроспектива — хороший момент, чтобы сказать: «В этом спринте нам не хватило навыков X или Y» или во время планирования: «Чтобы выполнить эти США, нам нужны X и Y, которых у нас нет в команде».
Это теоретические разговоры... На практике обычно коллирует тот, у кого есть бюджет.
В идеальном мире Scrum вам нужны не люди, а команды. Конечно, реальность другая. Ваш скрам-мастер прав, это не его обязанность, но он должен участвовать в обсуждении. Ваш Product Owner тоже прав, потому что это тоже не его ответственность. Его ответственность состоит в том, чтобы доставить, и когда это действие находится под угрозой, он должен что-то с этим делать. Пока изменение в настройке команды не повлияет на это, он должен быть в порядке с этим изменением. Кажется, что это ни на ком не лежит ответственность. Это один из недостатков Scrum. Создавшийся разрыв между развитием и управлением оставил эти вопросы открытыми.
Тем не менее, я склонен видеть неплохое решение этой проблемы: линейный менеджер, менеджер проекта, владелец продукта и скрам-мастер сидят вместе и ситуация. Когда у них есть понимание, они запрашивают предложение команды и вместе принимают решение .
Кто отвечает за изменение состава Скрам-команды?
Я бы созвал встречу и пригласил
Поскольку это изменение может повлиять на другие проекты, эти люди должны иметь возможность участвовать в обсуждении.
Менеджер, владелец продукта и скрам-мастер должны сесть вместе и обсудить это с вами, чтобы начать понимать, откуда вы пришли.
Владелец продукта должен иметь под рукой свой бэклог, скрам-мастер должен иметь под рукой сжигание, а менеджер должен иметь представление о бюджете и т. д.
Вы все обсуждаете, чтобы понять разные точки зрения, а затем, скорее всего, менеджеру нужно будет посмотреть, возможно ли это с финансовой точки зрения.
Затем вы сообщаете об этом команде, и пусть они решают.
Охотник на оленей
пвбливс