В последнее время я работаю и погружаюсь в Agile-пространство. Помимо прочего, меня вдохновило обещание, которое оно дает для расширения возможностей команды и максимизации эффективности. Однако у меня была одна незначительная проблема, для которой я еще не нашел конкретного решения: схемы вознаграждения и поощрения.
Вряд ли можно спорить о том, что одним из основных направлений Agile является «Команда». Кросс-функциональные команды собираются вместе и обязуются выполнять единицы работы в команде. В этом часто участвуют тестировщики, помогающие разработчикам, и наоборот. Индивидуальные линии и роли размыты в пользу максимальной сплоченности команды. Хотя команда поощряется к самоуправлению, на самом деле они не могут нести ответственность за окончательные схемы вознаграждения и стимулирования на организационном уровне. Ретроспективы ориентированы на открытость и доверие, и вряд ли это место для оценки индивидуального поведения. Однако эта система во многом напоминает коммунизм. Это, конечно, грубое сравнение, но когда я исследую схемы вознаграждения для людей, которые проводят много времени в своей команде Scrum/Kanban, в центре внимания всегда находится производительность команды, и поэтому сравнение двух разработчиков из разных команд несколько бесполезно. Хотя отход от традиционных, бюрократических методов оценки безусловно полезен, я все еще беспокоюсь о том, что люди не будут вознаграждены и на индивидуальной основе.
Таким образом, мой вопрос таков: полностью ли индивидуальные системы вознаграждения противоречат agile-философии (Agile буквально открывает совершенно новую парадигму в этом отношении?), и если нет, то как можно включить индивидуальные системы вознаграждения в Agile-ландшафт, не жертвуя при этом сплоченностью команды? ?
Индивидуальные вознаграждения и стимулы редко работают так, как предполагалось. Особенно в agile-команде. Как говорится в старой поговорке: «Скажи мне, как ты меня оценишь, и я покажу тебе, как я буду себя вести». Как сказал бы Спок: «Потребности многих перевешивают потребности одного».
Но, возможно, что еще более важно, подумайте, почему вы хотите вознаграждать людей и чем бы вы их наградили. В основном мы вознаграждаем людей, чтобы мотивировать их работать лучше. Оказывается, финансовые стимулы не работают для этого. Если вы действительно хотите мотивировать отдельных людей и команды, взывайте к их чувству автономии, мастерства и цели.
Почитайте "Драйв" Дэна Пинка . Увлекательное чтение.
В: Являются ли индивидуальные системы вознаграждения полностью противоречащими agile-философии? Ответ: Да
Есть исследования, показывающие, что бонусы, вознаграждения в сочетании с некоторыми поставками на самом деле контрпродуктивны в любом проекте, гибком или нет. (например , избавиться от обзора производительности )
Просто подумайте, чего вы хотите. Успешный проект или максимальное использование всех ресурсов? Любая цель, которую вы ставите заранее или на своем примере, которая не является «реализацией успешного проекта», отвлекает от этой цели. Вы хотите, чтобы все участники работали для достижения этой цели. Если проекту нужен определенный навык, которого у вас нет в команде, хотите ли вы наказать человека, который это делает, потому что он работает не так эффективно, как в своей зоне комфорта? Вы хотите оценить людей за то, что они работают дольше или работают умнее? В тот момент, когда вы награждаете поведение, отличное от «успешного проекта», вы говорите людям о своем реальном приоритете и просите обыграть систему.
В гибкой среде вы хотите, чтобы люди работали вместе. Индивидуальные награды заставляют их работать друг против друга. Иногда им придется выбирать между благом проекта и бонусом. Зачем вам такая система?
Я не думаю, что вознаграждение отдельных лиц противоречит гибкой философии/мышлению.
Пока награждаемые лица продемонстрировали отличное «отношение» прежде всего, я думаю, что это на самом деле поможет продвинуть дело гибкости, которое в IMO состоит в том, чтобы сосредоточиться на желаемом результате , а не просто на увеличении результата .
Я думаю, что также важно отметить вклад выбранного человека — таким образом, чтобы напомнить всем остальным в команде, что такое agile-мышление. Один из способов сделать это — конкретно упомянуть список личных достижений, демонстрирующих хорошее лидерство.
Я согласен с другими ответчиками в том, что индивидуальная мотивация несовместима с Agile. Еще несколько мыслей в дополнение:
Таким образом, один из рабочих подходов может состоять в том, чтобы поровну распределять внешние стимулы по всей команде, но привязывать индивидуальную производительность только к внутренним стимулам и таким образом, чтобы это помогало сплочению команды.
Например, попросите их время от времени оценивать свою работу и работу своих сверстников в неформальной обстановке, например, хвалить друг друга в конце спринта или благодарить других за ценную помощь. Это может быть даже в письменной форме, например, если вы запишете все такие похвалы и перечислите их в конце проекта/релиза на «сертификате», который вручается каждому члену команды, я почти уверен, что им это понравится и они будут дорожить им. на всю оставшуюся жизнь!
Я согласен с тем, что индивидуальные выступления следует осуждать, поскольку это противоречит «менталитету всей команды». Тем не менее, почему бы не попробовать ввести несколько видов деятельности для всей команды, которые одновременно и забавны, и помогают поддерживать свежесть командной деятельности. Вот пара вещей, которые я сделал со своими командами в прошлом, и они сработали хорошо.
Новые названия команд в каждом спринте — мы проводили мозговой штурм новых названий команд каждые 2 недели, а затем команда голосовала за них. Имена всегда будут производными от имени или фамилии человека в команде. Например, включение кого-то с фамилией Смит может быть приравнено к Fresh Prince of Bel Air (для Уилла Смита).
Заключайте мемы о рабочих соглашениях. Создавайте мемы с помощью одного из многочисленных генераторов мемов и размещайте их в своей рабочей зоне. Это делает вещи легкими и добавляет немного юмора в день. Например, у нас был мем Конфуция, который гласил: «Конфуций говорит, что у всех пользовательских историй есть критерии приемлемости».
Играйте вместе / устраивайте командные прогулки — регулярные командные прогулки не реже одного раза в квартал отлично подходят для того, чтобы веселиться и узнавать друг друга по-новому. Например, мы регулярно играли в мини-гольф всей командой и хвастались победителями.
Благодарите. В своих ретроспективах держите последний пункт повестки дня перед перерывом как возможность поблагодарить кого-то, кто помог вам, откликнулся или как-то еще замечательно. Это отличный способ завершить встречу на высокой ноте, и каждый ценит публичное признание.
Удачи!
Существует теория, согласно которой разные люди по-разному мотивированы примерно следующим образом: одной группе нравится ставить задачи и решать их. Тот факт, что они, как правило, делают свою команду успешной, является лишь приятным побочным эффектом. Второй группе нравится работать с другими людьми и участвовать в командной работе. Тот факт, что они, как правило, делают свою команду успешной, является лишь приятным побочным эффектом. А третья группа преследует только свою выгоду, больше денег, больше власти. Если команда добивается успеха, это не из-за них.
Попробуйте взять в свою команду членов группы №1 и группы №2, и у вас все получится. Дайте им то, что они хотят: вызовы и командную работу. Платите им достойно, потому что, хотя они хорошо работают без денежной мотивации, они будут хорошо работать для кого-то другого , если вы им не будете платить.
PS. Члены первых двух групп обычно вполне довольны признанием других.
Кирстен Клэйси