Scrum: справиться с отсутствием мотивации

В соответствии с этим «Scrum очень полагается на высоко мотивированные, тесно сотрудничающие, кросс-функциональные и самоорганизованные команды». Итак, как вы справляетесь с коллегами, которые, возможно, не так заинтересованы в том, чтобы стать владельцем кода? Как вы заинтересовались тем, чтобы стать владельцем?

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

Суть в том, что они никогда не приходили к нам, разработчикам, и спрашивали, как вы, ребята, хотите работать? что сделает вас счастливее? более эффективным?. Поэтому я услышал, что «у вас больше нет никакого кода. Все, что вы напишите, будет растоптано (вы знаете, владение командой). Вы не будете двигаться или поднимать палец, потому что теперь мы будем часами управлять вашим временем». О, и теперь у вас есть скучная 15-минутная стоянка каждый день, когда люди будут обсуждать вещи, которые вас не волнуют, и обычно это занимает 30 минут, а затем каждые две недели будет сверхурочное скучное 4-часовое совещание по планированию, которое обязательно будет отстойным. вся жизнь из тебя.

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

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

Я считаю, что ключевым изменением для нас было дать разработчикам гораздо больше голоса и свободы в выборе того, как мы хотим работать. Несколько вещей, которые мы сделали:

1. Разбейте большую «гибкую» команду разработчиков на 3 маленьких, чтобы у каждого было только 3-4 разработчика. Это заставляет всех заниматься, а люди не тонут.
2. Убедитесь, что все в одной команде работают в одной и той же функциональной области, чтобы людям было интересно, о чем говорят другие в режиме ожидания и итеративного планирования.
3. Вместо того, чтобы руководство просто выбирало, кто над чем работает и назначал истории / задачи, мы придумали отставание, и у самой команды было много слов в том, как распределить работу.
4. Поскольку у нас было много новых членов, мы начали с некоторой системы бункера, где каждый человек имеет основную зону ответственности. Это позволило новым людям сосредоточиться на меньшей площади неизвестного продукта, а также быстрее почувствовать, что они не играют в чужой песочнице. Но через 6-8 месяцев после начала программы эти области стали трансформироваться, поскольку границы стали более серыми. Теперь ребята из тех команд, в которых я работаю, довольно комфортно входят в чужой код или заставляют других разработчиков работать за них.
5. Обзоры кода всех представлений были ключевыми (и это было первое, на что было упущено, когда мы впервые сделали Scrum):
   • Передача знаний с точки зрения методов / методов программирования
   • Было здорово, когда другие изучали код, которого они не увидели бы иначе
   • Ваша команда получает возможность общаться и общаться, что улучшает командную динамику
   • И я думаю, что при проверке кода будет обнаружена одна или две ошибки, но я вижу их значение в основном в вышеуказанных аспектах.
6. Руководство должно прислушиваться к команде. Если команда говорит, что что-то не работает или нуждается в изменении, и они просто игнорируют это, то члены команды просто проверят и позволят руководству разобраться с проектом. Если вы хотите, чтобы люди были мотивированы, они должны быть наделены ими, и они будут наделены ими, только если они делают то, что считают правильным, а не то, что им говорят делать сверху.

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

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

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

Предоставляя им индивидуальную собственность над кодом.

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

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

Смотрите также: /software//a/33464/1204