31 декабря, 2017
Скрам мастер - кто он и какой он?
Самый популярный вопрос с конференций в 2017 году - а может ли ПМ НЕ быть в прошлом разработчиком?
Решила подойти к этому вопросу несколько иначе, ибо не ПМом единым же!
Тем более, что с декабря 2017 я - именно скрам мастер, в большом проекте с пятью командами, используя тот самый Less, где, как говорят мои студенты, скрам мастер носится по всем встречам и событиям, как обычно, но в истерике, так как команд много. И я вам скажу, после пяти лет в менеджменте, это такое счастье - не принимать решений, не считать бюджет и не писать отчеты, а сфокусироваться на команде и успехе каждого. Тем более, когда я могу прямо этому успеху помочь или воспрепятствовать.
Скрам мастер, который, судя по гайду, без власти, но с процессами и ресурсами? Кто он, в прошлом - таки проджект менеджер или разработчик?
Аджайл манифест писали разработчики. И логично предположить, что именно "один из них" и должен был трансформироваться в новую роль. Или нет?
Лично мне известно, почему некоторые руководители проектов испытывают трудности в роли Scrum Master. Потому что часто хочется применить COMMAND and CONTROL в скрам команде. И я в блоге описывала именно это как один из фейлов. На протяжении всей моей карьеры в качестве скрам мастера у меня ни разу не было обязанностей в стиле "проверять код". Что делать, если нет того самого бекграунда, неужели мне все будут врать и пытаться меня сьесть? НЕТ! Скрам мастер, лидер, да, НО НЕ ТЕХНИЧЕСКИЙ эксперт. Покажите мне хоть один источник "правды", который описывает, что скрам мастеру неободимо быть именно экспертом в разработке? Нас учат устранению препятствий, чтобы мы следили за тем, чтобы в команде было минимальное отвлечение, и вы знаете, что? Каждый скрам мастер (да и ПМ) знает, что если мы работаем в рисковом проекте (кстати, проект может быть максимально подвержен рискам, и максимально к ним толерантен, на мастер-классе мы об этом говорим), мы должны каждый день встречаться с командой, чтобы устранить препятствия. Звучит знакомо? Разумеется, как и сегодня Scrum Masters, большинство менеджеров проектов "старых назначений" были назначены из рядов функциональных менеджеров, которые были знакомы с директивным стилем управления, и многие любили статус «героя», зарезервированный для этих сверхпрофессионалов. Тоесть, раз уж ты руководишь проектом, то руководи и командой. И да, с таким подходом никакого сервант лидершипа не будет, будет в стиле "делайте, как я сказал".

Та же история с разработчиками. Есть много разработчиков, которые считают, что это поощрение, если ты стал скрам мастером. Это дает им возможность играть неуловимую роль «технологического лидерства» и управлять технологией. Ага! И по чуть чуть продавливать идеи архитектуры или development practices. Как разработчик с сильным мнением о том, как что-то нужно построить, может расслабиться и позволить команде самостоятельно организовывать решение, с которым он технически не согласен?

Чтобы быть эффективным скрам мастером, вы должны принять основные ценности Agile Manifesto. Я считаю, что есть равные шансы на неудачу или успех при выборе Scrum Master из рядов разработчиков или менеджеров проектов. Независимо от того, где вы находите своего Scrum Master, гораздо важнее, чтобы у них были необходимые навыки, чтобы быть servant leader; и среди таких навыков умение строить доверительные отношения, страсть к прогрессу и движению вперед. Помните вечное Changes are welcome? Неважно, какой у вас опыт в разработке или управлении, НО если вы НЕ готовы принимать изменния и считаете, что "раз в прошлой итерации у нас был такой дизайн, то сменить его - значит проработать впустую", то ваши шансы на успех именно в роли скрам мастера уменьшаются.
Made on
Tilda