Как вести себя с членом скрам-команды, который никогда не бывает на своем рабочем месте

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

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

Скрам-команда должна принять концепции мужества, открытости и уважения. Если один или несколько человек обеспокоены тем, как работает команда или член команды, между членами команды должно быть открытое общение, и каждый должен уважать их мысли и мнения.

Второе - стать тренером личности. Это может быть нормально, что он не за своим столом, если он участвует в работе. Однако, если он пропускает церемонии Скрама (например, Планирование Спринта, Ежедневный Скрам, Обзор Спринта или Ретроспективу Спринта) или не завершает работу из Бэклога Спринта, то он вредит всей команде. Попытайтесь понять, почему он не участвует, и объясните, как важно быть там и взаимодействовать с остальной командой.

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

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

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

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

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

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

Первая проблема, с которой мы столкнулись как команда, заключалась в том, что люди приходили и спрашивали о нем, а мы понятия не имели, где он и когда вернется. Это заставило нас выглядеть глупо, как будто мы не знали, чем занимаются другие люди в команде. Итак, мы подняли этот вопрос, мы сказали: «Эй, послушай, когда люди приходят и спрашивают о тебе, а мы не знаем, где ты и как долго тебя не будет, это заставляет нас выглядеть очень плохо, как будто мы не такие». команда или все равно. Как мы можем это исправить?» Мы договорились, что любойвыходя из комнаты больше, чем на короткий туалет или кофе-брейк, они просто говорили, куда они пошли. «Эй, команда, звонил Боб из группы бета-тестирования, ему нужна помощь с проблемой базы данных, я ненадолго спущусь вниз». Должно быть достаточно. Никакой волокиты, никакой процедуры или системы, только простое общение. Это решило для нас настоящую проблему и повысило осведомленность людей, которых нет «там». Никто не возражал.

Второй серьезной проблемой, с которой мы столкнулись, было слишком много задач вне команды. Это больше проблема PO, потому что внутри организации он получил бюджет для команды X человек, но только (X-?) люди работают над его задачами, с ? люди, работающие в основном над задачами других команд. Мы исправили это, добавив прозрачности , разместив на стене небольшую заметку с указанием того, что мы сделали и как долго. После спринта мы собирали их и решали, что с этим делать. Может быть, другие команды нуждаются в обучении, может быть, мы пропускаем задачу в нашей команде или, может быть, кому-то нужно время от времени говорить «нет». Каким бы ни было решение, убедитесь, что люди записывают то, что они делают для других. Тот парень, который постоянно в отъезде, должен много производитьиз тех. Напомните ему, если он забудет. Работайте над сокращением этого количества «выходящих за рамки» работ. Не нацеливайтесь на него конкретно, нацеливайтесь на проблему: работа, сделанная для других.

Итак, подведем итог: команда должна улучшиться и заняться реальными проблемами, которые существуют. Упомянутый человек является частью команды и должен иметь право голоса. Дело не в нем или его поведении, а в решении проблем. Его отсутствие рано или поздно автоматически сократится, когда проблемы будут решены. Ваша работа как скрам-мастера состоит в том, чтобы помочь команде сделать это.

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

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

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

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

Как скрам-мастер, первое, что я хотел бы понять, — это мотивация такого поведения. Почему они не хотят проводить время за рабочим столом?

Во-вторых, я бы сосредоточился на проблемах, вызванных поведением, а не на самом поведении. Если они ведут себя так, но команда по-прежнему высокопродуктивна, то проблем нет. Однако, возможно, есть такие проблемы, как:

• Задержки, когда члены команды ждут, пока этот человек вернется к своему рабочему столу
• Непонимание, поскольку человек не мог ответить на вопросы

Если такие вопросы возникают, то их следует поднимать на ретроспективе. Что-то вроде:

Этот последний выпуск был болезненным, потому что мы не понимали, что база данных не была обновлена. Можем ли мы как команда сделать эту информацию более доступной?

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

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

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

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

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

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

Чем меньше времени он сэкономит , не придя (т. е. чем дольше ваши встречи с ним до и после), тем выше шансы, что он придет.

(Но дайте ему понять, что вам нравятся эти встречи с ним, иначе он поймет, что вы сдадитесь раньше него.)

Определите, есть ли у вас проблема: если работа члена команды хороша, пусть так и будет.

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

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

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

• срочный элемент BAU, который должен быть выполнен прямо сейчас
• Разработчик заблокирован и хотел бы на некоторое время соединиться/скопиться
• PO хочет обновить статус

...или что-то еще, что может помешать членам Команды, активно работающим над Инкрементом.

Однако, если «никогда не находится на своем рабочем месте» означает, что этот Разработчик недоступен для Команды, то его резервные мощности не могут быть использованы эффективно или вообще не могут быть использованы.

Как указывали другие, здесь может не быть проблемы. Я думаю, мы можем провести параллель с ПО; то есть PO обычно физически отсутствует в Команде в течение определенного периода времени, но если он выполняет свою роль (Scrum Events и т. д.) и поддерживает разумную доступность для Команды для уточнения, предоставления отзывов и т. д., тогда проблем должно быть немного.

Один положительный аспект заключается в том, что (предположительно) это очень заметно, когда этот разработчик не работает активно над Инкрементом. Их пустой стул очень прозрачен для Команды. Лично я предпочитаю сидеть в кресле и класть ноги на стол, когда никто не дает мне ничего делать (когда я скорее думаю, что они должны быть), это посылает действительно четкий сигнал! Как SM, я бы предпочел увидеть пустой стул, чем узнать после того, как разработчик сидел за своим столом, «улучшая» элементы в бэклоге продукта в одиночестве. Я также задавал вопросы, чтобы убедиться, что все остальные в Команде искренне довольны всем этим «пустым стулом».

Возможные дисфункции, над которыми стоит задуматься:

• Члены команды не могут привлечь друг друга к ответственности.
• Отдельные лица решают Препятствия по мере их возникновения (а не сообщают о них Команде).
• Препятствия поднимаются только в Daily Scrum/Retro.
• I-образные люди (а не Т-образные люди).
• Отдельные лица, работающие над задачами (а не команда, работающая над выполнением Инкремента)
• Элементы Бэклога Спринта «принадлежат» отдельным лицам (а не Команде).
• Другие разработчики также имеют частые «пробелы», но не говорят об этом открыто.