Каковы недостатки менеджеров по развитию как Scrum Masters?

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

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

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

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

Пожалуйста, расскажите мне о подводных камнях менеджеров по развитию, таких как Scrum Masters, за исключением пунктов, которые я поднял выше и уже преодолел.

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

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

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

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

Вы все еще можете это сделать? Конечно. Вам просто нужно очень усердно работать, чтобы подтвердить, что вы лидер-слуга и сверху вниз не полетите.

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

(Кстати, это был не мой менеджер, поэтому я чувствую себя достаточно объективным в этом вопросе.)

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

1. Технические руководители обычно отвечают за определенную роль в нескольких командах. Если это только одна команда, то это скорее «лидерство», чем «менеджер». Такое распределение ответственности означает меньше времени для команды и меньше времени для проекта / продукта, и, как правило, приводит к управлению стилями «наезд и беги».

2. Технические менеджеры имеют много других управленческих обязанностей для бизнеса. Они должны проводить коучинг / обучение, анализ производительности, интервьюирование / прием на работу, долгосрочное планирование инфраструктуры / ресурсов и многое другое. Это может легко стать работой на полный рабочий день само по себе и означает, что очень мало остается потратить на содействие.

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

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

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

6. Члены команды всегда будут иметь проблемы с разграничением между запросом и заказом. Они не скажут вам этого и могут даже не осознавать этого сами. Даже если вы ясно даете понять, что вы просто спрашиваете, а не говорите, в их умах вы все равно являетесь их менеджером, и есть риск на уровне карьеры, чтобы сказать «нет». Это, вероятно, самая коварная из всех проблем, потому что вы ничего не можете с этим поделать - важно их отношение, а не ваше .

Если вы уверены, что никогда не попадете ни в одну из этих ловушек, тогда сделайте это ... но я повторяю, убедитесь, что вы часто проверяете свои предположения, общаясь со своей командой (и другими командами / менеджерами!) и убедитесь, что они не происходят тонким или неосознанным образом, который, возможно, вы не замечаете.

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

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

Это не религия и правила Scrum не догматичны. Если когда-либо был случай для комбинированной роли HR Manager / Srum Master, вы сделали хорошую. Будьте внимательны к тем ловушкам, о которых вы упомянули, но никогда не будет единого набора правил, который бы идеально подходил к любой ситуации.

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

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

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

В любом случае, вы оказываете негативное влияние на команду.

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

Ниже приведены две возможные организации команды. Оба могут быть успешными. Они разные. (Они не единственные возможные варианты.)

1. У команды есть официально назначенный лидер. Лидер команды в конечном счете несет ответственность за общую производительность команд. Лидер команды может принимать не все решения, но лидер команды имеет решающее значение при принятии всех решений.
2. Команда самоорганизуется и не имеет официально назначенного лидера. Каждый в команде несет ответственность за свою собственную и общую производительность команды. Scrum Master облегчает процесс Scrum, но не уполномочен принимать односторонние решения для команды.

Похоже, что ваша реальная структура команды - № 1, но, используя терминологию и несколько процессов из Scrum, вы подразумеваете, что структура № 2. Мое мнение, что № 1 не Scrum.

Ниже приведены два предложения о том, как разрешить конфликт.

1. Продолжайте делать все как есть, но уточните, что вы являетесь лидером команды и не следите за Scrum на 100%. Вероятно, это поможет объяснить, что, хотя вы видите ценность в разделении обязанностей менеджера и начальника, это неосуществимо для компании.
2. Передайте обязанности Скрам Мастера, насколько это возможно, кому-то еще. Даже если вам все еще придется сохранить некоторые обязанности, такие как устранение препятствий и отвлечение внимания от остальной части организации, это все равно поможет выполнить большую часть работы Scrum Master одним партнером.

Каковы недостатки менеджеров по развитию как Scrum Masters?

Менеджеры по развитию нанимаются для:

• Решить проблемы развития .
• Мониторинг и сокращение технического долга.
• Вырастить технический персонал.

Их опыт и знания предрасполагают их сосредоточиться на технических вопросах .

С другой стороны, наняты менеджеры проектов / мастера схваток;

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

• Когда проект или компания достигают определенного размера, неэффективно и неразумно просить менеджера по развитию выполнить обе обязанности.

• Менеджер по разработке должен быть склонен к «глубокому погружению» в код и / или архитектуру, в то время как менеджер по проектам / мастер-класс Scrum всегда должен заботиться о взгляде на вещи с высоты 50 000 футов.

• Большинство менеджеров по разработке потратили годы на разработку кода. Вопросы развития им очень знакомы.

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

Я бы послушал опытных тренеров по схватке. Вполне возможно, что вы бы хорошо работали в течение 99% времени. Однако, когда приходит этот страшный 1% и конфликт ролей, у вас есть шанс испортить не только отношения с вами, но и благополучие всей команды. И после одного провала ваша роль как мастера схватки и менеджера будет подорвана.

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