Как вы управляете продвижением при использовании Scrum?

Я проклят благословением высокоэффективной Scrum-команды.

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

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

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

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

У кого-нибудь есть опыт решения этой проблемы? Любые примеры методов, которые работали? Один подход, который я рассматриваю, — это разграничение уровней на основе влияния, которое члены моей команды оказывают вне команды (проводя обучение для других, тратя время на помощь другой команде в решении проблем). Кто-нибудь использовал этот подход? Получилось?

Уточнения

  1. Это единственная Scrum-команда в компании. Остальные команды в компании структурированы более иерархически, что хорошо подходит для иерархической организационной схемы.
  2. Я не ошибаюсь в своей оценке, что моя команда состоит из отличников. В команде нет мертвого груза. Неделю за неделей будет выделяться тот или иной человек, но ни один человек не будет постоянно выделяться среди других.
  3. Моя основная причина, по которой я хочу соответствовать общекорпоративному подходу, заключается в том, чтобы члены моей команды не задерживались, находясь в моей команде, и, когда придет время для них переехать, они были в хорошей позиции для этого.
Вы говорили об этом со своим менеджером или HR? Я не уверен, что вы подразумеваете под «соответствующим уровнем», и не ясно, что именно делает остальная часть компании и как, по вашему мнению, это не применяется.
Мой менеджер является основателем компании, а наш отдел кадров (каким бы он ни был) на самом деле не укомплектован персоналом, чтобы предоставить такую ​​​​информацию.
Что касается распределения по уровням, в других командах разработчиков есть «старшие разработчики» и «архитекторы», которые отличаются тем, что берут на себя всю ответственность за проблемы и передают работу младшим разработчикам; это очень нисходящий подход, поэтому многоуровневость имеет смысл. Scrum абсолютно не такой. В команде нет иерархии — это команда равных. Здесь трудно уместить многоуровневость.
Как всегда; вознаграждайте тех, кто решает самые сложные проблемы, поддерживает высокий индивидуальный ритм, приносит наибольшую пользу команде как внутри, так и, как вы предлагаете, для клиентов, как внутренних, так и внешних. Такая же оценка, как и у любого менеджера, за исключением того, что у вас есть лучшие записи, на которые можно опереться.
Основатель тоже борется. Да... эти уровни должны быть связаны с должностями.
Команда вообще просит об этом изменении? Если нет, и основатель не знает, как ее решить, то зачем ее форсировать? Просто оставьте его в покое, пока один из этих членов команды не начнет просить об изменении названия.
К сожалению, основателей больше, чем один, а остальные сосредоточены на остальной части компании. Наша команда Scrum является чем-то вроде загадки для остальных.

Ответы (3)

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

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

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

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

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

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

У кого-нибудь есть опыт решения этой проблемы?

Конечно.

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

Тем не менее, ваш вопрос оставляет меня с двумя основными проблемами:

  1. Кажется, вы предполагаете, что ваша команда статична. В лучшем случае скрам-команды будут меняться в зависимости от того, какую работу вы выполняете, добавляя и удаляя людей с нужными навыками для решения проблем. В то время как ваша текущая сплоченность может быть полезна для вашей команды, это может быть плохо для компании. Хуже того, если ваша команда застряла в вашей команде даже с повышением, вы вдруг станете тем, кто блокирует их карьерный рост. Подумайте, какие возможности существуют для вашей команды за пределами вашей компетенции. Это может не иметь отношения к этим ролям, но если ваша команда не сможет добиться от вас продвижения по карьерной лестнице, они найдут его в другом месте.
  2. "Все выдающиеся исполнители"? Вряд ли. Когда у вас есть группа людей, они будут иметь некоторые естественные различия в своих способностях. Конечно, у каждого из них есть свои сильные стороны, но некоторые из этих сильных сторон, естественно, будут более ценными для вашей компании — либо из-за их редкости, либо из-за их полезности. Когда дело доходит до драки, кто проходит? Коллеги в значительной степени знают, кто настоящие звезды в их группе, и не держат зла, если этот человек получает соответствующую компенсацию, поскольку это укрепляет идею о том, что они получат соответствующую компенсацию, когда им станет лучше. Даже в командах, которые сосредоточены на равенстве и командной работе.
Хорошие моменты; однако относительно 1), это на самом деле большая часть того, почему я хочу найти решение. Рано или поздно члены моей команды захотят двигаться дальше, и я не хочу, чтобы они стояли в тупике из-за того, что они были в единственной команде Scrum в компании.
По поводу 2) тут вы ошибаетесь. На самом деле мне повезло, что у меня есть очень высокоэффективная команда без мертвого груза. Неделя за неделей тот или иной человек может выделяться, но с течением времени команда в целом становится лучше.
@Dancrumb - я не говорю о мертвом весе. Я говорю о члене команды, который на несколько шагов впереди других отличников или даже того, кого немного сложнее заменить. Я могу ошибаться, но в 9+ случаях из 10 это ощущение «все замечательно» вызвано разрывом между менеджером и повседневной работой.
Это справедливое замечание. Я уделю этому некоторое внимание.
Ваш первый пункт превосходен. Это относилось ко мне раньше, все стало очень статичным с точки зрения карьерного роста, поэтому я пошел дальше и нашел прогресс в другом месте.
+1. Не путайте скрам с коммунизмом — у членов вашей команды разные навыки, разное количество навыков и разная стоимость на открытом рынке. Один может быть «великим» младшим разработчиком, а другой «великим» архитектором — они оба великолепны, но если вы вознаградите их одинаково, вы останетесь только с отличными младшими разработчиками — я думаю, вы можете поспорить, что они не берут все. как эгалитарны, как вы думаете, вещи.

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

Ты нуждаешься во мне .

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

Тебе нужна моя команда .

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

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

Я нужен тебе как часть команды .

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

Как вы управляете продвижением при использовании Scrum?
СпросиСетьПолитика конфиденциальности1y, 0v