Должен ли Скрам-мастер также выполнять роль функционального менеджера?

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

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

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

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

• Пропущенные сроки/цели командой не должны быть связаны с вашими решениями о найме/увольнении. Процесс найма может быть изменен, чтобы провести сеанс коллегиального собеседования со всей командой
• Члены команды не должны начинать скрывать прогресс/препятствия/оценки в зависимости от вашего неудовольствия/удовольствия.
• Скрам-мастер должен продолжать давать частые отзывы о производительности и тренировать команду.
• Команда должна продолжать управлять ежедневными стендапами (мастер схватки просто следит за тем, чтобы ежедневные стендапы выполнялись).
• Команда не должна начинать отчитываться перед скрам-мастером
• Обзоры производительности должны основываться на оценке, сделанной всеми членами команды, включая скрам-мастера.

TL;DR

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

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

Скрам-мастер — это не линейный менеджер

Работа скрам-мастера состоит в том, чтобы судить о скрам-процессе, обучать команду и организацию работе со скрамом и передавать информацию о проекте владельцу продукта и организации в целом. Хотя нет ничего невозможного в том , чтобы наделить скрам-мастера управленческими полномочиями, это активно работает против принципов самоорганизации, которые призван поощрять скрам.

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

Организационные изменения — это сложно

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

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

Менеджмент тоже нуждается в изменениях

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

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

Я являюсь менеджером по разработке приложений на этой должности, и она отлично работает для моей команды. Главное – отличие мышления от традиционного менеджмента. У меня есть преимущество в том, что я строю команду с нуля, поэтому с самого начала ясно дал понять, что я здесь, чтобы помочь им, и они принимают решения больше, чем я. Сначала команде потребовалось некоторое время, чтобы действительно поверить, что они принимают решения и полностью контролируют ситуацию, но после нескольких ретроспектив, искренне слушая и внося изменения, которые ОНИ решают, они теперь готовы выносить на обсуждение все, что угодно.

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

Если вы отдадите право собственности команде, они возьмут на себя ответственность.

Есть отличный пост, опубликованный http://www.sitepoint.com/managers-make-terrible-scrum-masters/ . Я призываю прочитать все это. Вот несколько цитат оттуда, чтобы донести мысль:

Между обязанностями менеджера и скрам-мастера существует базовый конфликт интересов.

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

...

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

...

Создание и курирование команды является основной обязанностью менеджера.

У нас была такая ситуация; у нас также была ситуация, когда PO был также SM. Они совсем не помогли командам и не принесли улучшения. Ничего не произошло.

Проблема в том, что у функционального менеджера есть повестка дня. У РО есть повестка дня.

- Повестка дня SM другая и имеет другую направленность. Много раз SM приходится спорить с функциональным менеджером, чтобы получить преимущества для команды или внести изменения, которые выгодны для команды (но, возможно, не так много для менеджера). Для функционального менеджера практически невозможно стать достаточно объективным, чтобы «служить руководить» командой. Особенно, когда у них есть цели по производительности, которые нужно выполнить.

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

В идеале скрам-мастер — это просто скрам-мастер. Также может быть тренером, но это все. Они могут быть в руководстве / исполнительном совете, чтобы влиять на принятие решений для компании, но всегда сохраняя шляпу лидера-слуги. В тот момент, когда вы даете ему / ей функцию управления, вы нарушаете всю концепцию Scrum Master, то, как команда взаимодействует. человеку, как человек влияет на команду, доверие команды к человеку.

TL;DR: нет, у функционального менеджера другая повестка дня, и он не объективен для выполнения роли Scrum Master, а команда не доверяет и не относится к SM, который также является боссом.