Что ожидается от разных уровней карьеры Скрам-мастера?

Я думаю, что различные уровни могут относиться к Agile Onion, описанному Саймоном Пауэрсом .

Начальный уровень : Может внедрить инструменты и процессы, но плохо понимает, почему существуют процессы, практики, принципы и ценности. Может привести к карго-культу Agile .

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

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

Гуру : Руководит (крупными) успешными Agile-трансформациями, пишет книги и т. д.

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

SM среднего уровня, как правило, очевидны из-за их навыков общения с людьми. SM среднего звена — это лидеры (не в традиционном смысле менеджера, но это те, на кого команда склонна смотреть и на кого полагаться). SM среднего уровня отлично подходят для создания сплоченности команды, и командный дух, как правило, высок. На этом уровне Sm, как правило, становится намного удобнее, используя свой опыт, чтобы смотреть на прошлые спринты и иметь возможность делать прогнозы о будущей работе, что делает их очень полезными для типов PMO. SM на среднем уровне может не только помочь организовать совещание по планированию, но и имеет опыт работы с командой и может дать оценки того, что может или не может быть слишком большим элементом, чтобы взять его на основе прошлой работы. Это, как правило, очень помогает техническим руководителям и бизнес-аналитикам.

Старшие SM, как правило, погружаются в управленческие функции, которые (на мой взгляд) являются слабым местом Agile Scrum. Старшие SM часто участвуют в организации общепроектных инициатив, контролируя работу SQA (организационно), следя за тем, чтобы команды занимались необходимыми областями, когда речь идет о проблемах с выпуском, приоритезации дефектов и т. д. Для более крупного проекта они, как правило, заполняют пустота, оставшаяся там, где «самоорганизация» в основном терпит неудачу (что-то большее, чем 40 человек или около того), и вступают во множество ролей, традиционно выполняемых персоналом PM или PMO. К сожалению, это означает, что старшие SM часто слишком тонко распределяются между слишком большим количеством обязанностей.

Джуниор

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

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

Средний

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

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

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

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

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

Старшая

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

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

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

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

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

SSM должен стать «человеком за кулисами» — помогать команде в ее Agile-зрелости, не вмешиваясь, и учить команду запускать scrum-процессы самостоятельно все больше и больше.

Гуру

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

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

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

TL;DR

Вы пытаетесь применить устаревшую иерархию к платформе, которая явно отвергает понятие групповой иерархии. Это делает сам вопрос анти-шаблоном в Scrum.

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

Анализ и рекомендации

Руководство по Scrum 2020 не делает таких различий. В структуре есть только три определенные роли/обязанности, и нет условий для времени в классе или уровней опыта для названий ролей.

При этом, безусловно, есть зрелые команды и (в смысле CMMI ) незрелые команды. Есть также люди, которые плохо знакомы с фреймворком или своей ролью в нем. Однако, хотя это различие может быть полезным при определении того, как помочь команде принять структуру или успешно адаптироваться к ней, важно понимать, что среда Scrum не признает таких различий:

В Скрам-команде нет подкоманд или иерархий.

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

[Скрам-команда] самоуправляема, то есть они внутренне решают, кто, что, когда и как делает.

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

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

Высшее руководство всегда в конечном итоге отвечает за «тон наверху». Если они нарушат процесс Scrum, преднамеренно или нет, то они сохранят обе половины. КЭД

Конец примечания: определения являются относительными

Также стоит отметить, что различия в опыте — и денежное или политическое значение этих различий — часто относительны. В то время как многие ИТ-организации часто разрабатывают свой собственный лексикон или время в классе для уровней опыта (например, многие компании используют 5 лет в качестве произвольной точки отсечки, в то время как другие используют часто опровергаемый метод 10 000 часов ), реальность такова, что различия, как правило, идиосинкразические и специфичные для компании, и часто формулируются на основе сочетания существующей корпоративной культуры, конкретной проблемной области и текущего уровня опыта (как бы он ни определялся) существующего персонала.

В качестве примера предположим, что у меня более 20 лет опыта работы с некоторыми языками программирования. Если у вас всего 10, но вы лучше меня владеете этим языком, кто из нас "старший"? Если я был профессиональным экспертом в предметной области (SME) в чем-то в течение десяти лет, но у вас есть мастер в той же области с пятилетним опытом, делает ли это вас «подмастерьем SME» или мы, возможно, сверстники с какой-то другой карьерный опыт?

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

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

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