Недавно я присоединился к фантастической компании, которая гордится своей философией Agile и трудовой этикой. Я ОЧЕНЬ младший менеджер проектов, и чем больше я узнаю о Scrum и Agile, тем больше я хочу специализироваться в этой области. Однако я вижу две потенциальные проблемы:
Я прошла обучение на консультанта и психолога, поэтому моя настоящая страсть — это люди и объединение людей. Что мне нравится в роли Scrum-мастера, так это то, что он помогает людям на рабочем месте. Компания взяла меня на работу, так как увидела потенциал и захотела обучить меня в этой сфере. Тем не менее, я обеспокоен тем, что без технического образования вкупе со столь младшим возрастом я мог бы оказаться неэффективным в этой конкретной роли.
Возможно ли или даже возможно ли войти в ИТ-индустрию в роли Scrum Master? Если да, есть ли у кого-нибудь какие-либо рекомендации или уроки, извлеченные из похожего положения когда-то? Буду признателен за любые практические советы.
Я бы с большой осторожностью сразу стал Скрам-мастером, так как вы рискуете быть воспринятым командами очень негативно. Я скрам-мастер с опытом работы в сфере разработки, что позволяет мне естественным образом вписаться в команду и не выглядеть как «руководство».
Скрам-команды состоят из трех этапов, которые иногда называют Шу-Ха-Ри; термин боевых искусств. Ваш опыт будет означать, что в некоторых из этих штатов вам будет легче вписаться в команду, чем в других.
На этапе «Шу» (подчинение) команды изучают основы. Это требует от скрам-мастера большей принуждения, и именно здесь технические знания будут наиболее полезны. Именно здесь команды, вероятно, будут создавать свои «лучшие методы разработки», поэтому для меня скрам-мастер должен обеспечивать проверку кода, помогать внедрять XP или любой другой подход, который использует организация, и предлагать (часто технические) дополнения к определению. сделано. Именно здесь многие «консультанты по Scrum» (которые часто не являются техническими специалистами) кажутся мне подвохами отрасли — они приносят двухнедельные спринты, самоорганизующиеся команды и невыполненные работы, но не обращаются к самой важной части — основной разработке. стандарты, на которые был построен Scrum и на которые он опирается. Большинство команд никогда не покидают этот этап,
Следующим этапом, которого достигают команды, является «Ха» (отступление), когда они работают как хорошая команда Scrum и начинают понимать, почему они что-то делают, а не просто следуют процессу. Здесь у команды есть основы и она уже работает как хорошая команда. На этом этапе у них должны быть хорошие практики разработки, поэтому скрам-мастер, который менее техничен, вероятно, мог бы обойтись. Команда мотивирована поддерживать свое техническое совершенство, поэтому скрам-мастеру не нужно руководить этим, но он может постоянно напоминать команде о необходимости поддерживать свое техническое совершенство. По-прежнему существует риск того, что методы разработки могут ускользнуть, а команда этого не заметит, и, не будучи техническим специалистом, скрам-мастер может никогда не узнать об этом.
Если у вас есть редкий шанс поработать с гиперпродуктивной командой в «Ri» (отдельно), я не думаю, что вам нужно быть техничным. Это, вероятно, лучшая команда, подходящая для вашей ситуации. Ваш психологический опыт, вероятно, поможет вам лучше, чем большинство скрам-мастеров, разобраться в глубоких, скрытых проблемах, которые многие скрам-мастера могут упустить, поэтому вы можете попытаться специализироваться на работе с замечательными командами, которые пытаются вытравить дополнительные улучшение. Именно здесь команды придумывают свои собственные способы работы, возможно, вообще отказываясь от Scrum.
У меня есть опыт разработки программного обеспечения, и я провел несколько организаций через этапы Shu и, возможно, Ha — часто после того, как agile-консультанты уже нанесли большой ущерб, внедрив Scrum без какого-либо учета методов разработки, на которые он опирается. Если вы участвуете в внедрении Agile, обязательно поработайте с менеджером по разработке или старшим разработчиком, чтобы внедрить передовой опыт, ДО внедрения Agile. Без этого Скрам-мастера, не являющиеся техническими специалистами, могут серьезно разрушить команды и организации. Вы можете это сделать, но чем больше технических знаний вы получите, тем лучше.
Технические навыки не являются абсолютно необходимыми. На самом деле вы можете спорить в обоих направлениях:
Не имея технических навыков, вы освобождаетесь от попыток проанализировать техническую проблему и попытаться найти техническое решение, помогая команде выявлять проблемы сотрудничества и коммуникации и устранять нетехнические препятствия. Имея опыт работы в области психологии, вы сможете задавать членам команды прямые, наводящие на размышления вопросы, которые приведут к устранению препятствий или помогут вам обратиться к нужным людям.
Наличие технических навыков позволит вам различать простые препятствия, вызванные небольшими проблемами или недостатком знаний, и гораздо более серьезные проблемы, вызванные глубокими сложностями, которые не могут быть решены на месте. Более глубокое понимание технологии позволит вам быстро определить, кому следует передать проблему, или даже предложить команде, что «копать глубже» в отношении определенного препятствия/темы не стоит ценности для бизнеса.
Что касается джуниора и роли наставника, ИМХО, вы должны рассматривать роль Скрам-мастера как роль лидера-слуги, а не роль наставника. Хотя вы действуете как наставник в отношении самого процесса, вы служите команде в отношении ежедневного потока и цели создания ценности для бизнеса. Вы сосредотачиваетесь на устранении тех препятствий, с которыми разработчики и так не любят иметь дело («люди», вопросы управления и т. д.), и сосредотачиваетесь на том, чтобы собрать нужных людей вместе в нужное время. Из моего личного опыта в качестве Scrum-разработчика, Scrum-мастера, а теперь и менеджера команды, я могу сказать, что до сих пор я не встречал опытных разработчиков, отказывающихся работать с младшим Scrum-мастером только из-за возраста/опыта. у меня естьвидел разработчиков, не желающих работать со скрам-мастером, который не полностью понимает процесс: то есть, как младший скрам-мастер, сосредотачивайтесь на 100% на понимании Scrum, Agile и Lean и обеспечении ценности для бизнеса, постоянно ставя под сомнение и улучшая процесс.
Да, войти в ИТ-индустрию в роли Scrum Master можно даже с низким техническим образованием. Это не является ключевым моментом в вашей работе. Это больше о понимании команды и устранении препятствий.
Тем не менее, я хотел бы призвать вас создать свой собственный небольшой технический фон, потому что в некоторых случаях вам нужно будет понять некоторые технические вопросы, высказанные во время встреч, или, возможно, устранить препятствия или запросить помощь для других областей компании.
Обратите внимание, послушайте, что происходит, а затем прочитайте и узнайте о концепциях. Только концепции, только основные идеи.
Когда вы поймете основные концепции и то, как эти концепции связаны между собой, возможно, настало время сделать еще один шаг: проверить, что происходит с концепцией X, задать вопросы вашей команде в неформальной форме, спросив: Я понимаю Y, потому что в последняя встреча это случилось Z, я ошибаюсь?
Это не вызывает до тех пор, пока команда, с которой вы работаете, воспринимает это положительно. Но в большинстве случаев технические команды ожидают, что Скрам-мастер обладает техническими знаниями. Как новая пчела, если у вас его нет, это не создает для вас проблемы. Со временем вы сможете получить знания о технологиях и разработке вашего проекта/продукта, которые помогут вам понять, о чем говорят технические команды.
Если вы не набираете скорость, команды будут смотреть на вас как на проблему. Потому что долгое управление технической командой без понимания их проблем или того, что они на самом деле делают, не будет работать дольше.
Просто начните с «0» и накапливайте знания по ходу дела. Это должно работать.
Сначала они могут обратить внимание на ваши организаторские способности и навыки управления проектами. Если они впечатлены, наверняка любой позитивный член команды поддержит вас в обучении.
IMO, вы должны получить как минимум 3-4 года опыта работы в различных ролях, таких как разработчик (бэкэнд или интерфейс), QA, прежде чем погрузиться в роль Scrum-мастера. Опыт, полученный при работе в качестве члена команды, будет бесценным и позволит оценить роль SM. В противном случае вы будете применять книжные знания, полученные на двухдневном семинаре по СМ.
Фух. Пожалуйста, не делайте этого. Я действительно не думаю, что ты знаешь, во что ввязываешься. Пусть разработчик будет «мастером Scrum», и вы должны сосредоточиться на вещах типа менеджера проекта, таких как планирование встреч, работа с электронными таблицами и тому подобное.
Слушай, я могу понять, почему высшие актеры на сцене хотят вмешиваться в эти вещи. Дополнить резюме модными словечками, завоевать авторитет «на бумаге» в отрасли и т. д. Но с чистой точки зрения эффективности это не работает. Я видел это несколько раз — это действительно может разорвать команду на части. Все эти разговоры о «психологии» и «помощи людям объединяться» — это здорово, и все такое, и благородно, но этого не произойдет, все будет наоборот. Поверьте мне.
страшилка
Кирстен Клэйси